rust/tests/ui/lint/lint-forbid-attr.stderr

error[E0453]: allow(deprecated) incompatible with previous forbid
  --> $DIR/lint-forbid-attr.rs:3:9
   |
LL | #![forbid(deprecated)]
   |           ---------- `forbid` level set here
LL |
LL | #[allow(deprecated)]
   |         ^^^^^^^^^^ overruled by previous forbid

error[E0453]: allow(deprecated) incompatible with previous forbid
  --> $DIR/lint-forbid-attr.rs:3:9
   |
LL | #![forbid(deprecated)]
   |           ---------- `forbid` level set here
LL |
LL | #[allow(deprecated)]
   |         ^^^^^^^^^^ overruled by previous forbid
   |
   = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0453`.
Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by #70918) to fix the regression noted in #70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. 2020-11-07 17:14:38 -06:00			`error[E0453]: allow(deprecated) incompatible with previous forbid`
Remove licenses 2018-12-25 09:56:47 -06:00			`--> $DIR/lint-forbid-attr.rs:3:9`
Move compile-fail tests with NOTE/HELP annotations to UI 2017-12-10 13:47:55 -06:00			`\|`
Update UI tests 2018-02-22 18:42:32 -06:00			`LL \| #![forbid(deprecated)]`
Move compile-fail tests with NOTE/HELP annotations to UI 2017-12-10 13:47:55 -06:00			\| ---------- `forbid` level set here
fix one more case of trailing space 2022-06-08 13:07:59 -05:00			`LL \|`
Update UI tests 2018-02-22 18:42:32 -06:00			`LL \| #[allow(deprecated)]`
Move compile-fail tests with NOTE/HELP annotations to UI 2017-12-10 13:47:55 -06:00			`\| ^^^^^^^^^^ overruled by previous forbid`

Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by #70918) to fix the regression noted in #70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. 2020-11-07 17:14:38 -06:00			`error[E0453]: allow(deprecated) incompatible with previous forbid`
Update tests 2020-01-08 11:02:10 -06:00			`--> $DIR/lint-forbid-attr.rs:3:9`
			`\|`
			`LL \| #![forbid(deprecated)]`
			\| ---------- `forbid` level set here
fix one more case of trailing space 2022-06-08 13:07:59 -05:00			`LL \|`
Update tests 2020-01-08 11:02:10 -06:00			`LL \| #[allow(deprecated)]`
			`\| ^^^^^^^^^^ overruled by previous forbid`
Add a note to duplicate diagnostics 2023-10-04 13:34:50 -05:00			`\|`
			= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
Update tests 2020-01-08 11:02:10 -06:00
Don't pass -Z unstable-options by default for UI tests - Pass it explicitly where appropriate - Update stderr files and warnings; it turns that unstable-options has far-reaching effects on diagnostics. 2021-02-28 12:24:46 -06:00			`error: aborting due to 2 previous errors`
Move compile-fail tests with NOTE/HELP annotations to UI 2017-12-10 13:47:55 -06:00
update tests 2018-03-03 08:59:40 -06:00			For more information about this error, try `rustc --explain E0453`.