nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-06-05 19:58:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
5b0324fce0
rust/tests/ui/lint/lint-forbid-cmdline.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

20 lines
608 B
Plaintext
Raw Normal View History

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 23:14:38 +00:00
error[E0453]: allow(deprecated) incompatible with previous forbid
Remove licenses
2018-12-25 15:56:47 +00:00
--> $DIR/lint-forbid-cmdline.rs:3:9
Moved compile-fail tests to ui tests.
2018-08-08 12:28:26 +00:00
|
Update tests
2019-03-09 12:03:44 +00:00
LL | #[allow(deprecated)]
Moved compile-fail tests to ui tests.
2018-08-08 12:28:26 +00:00
| ^^^^^^^^^^ overruled by previous forbid
|
= note: `forbid` lint level was set on command line
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 23:14:38 +00:00
error[E0453]: allow(deprecated) incompatible with previous forbid
Update tests
2020-01-08 17:02:10 +00:00
--> $DIR/lint-forbid-cmdline.rs:3:9
|
LL | #[allow(deprecated)]
| ^^^^^^^^^^ overruled by previous forbid
|
= note: `forbid` lint level was set on command line
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 18:24:46 +00:00
error: aborting due to 2 previous errors
Moved compile-fail tests to ui tests.
2018-08-08 12:28:26 +00:00
For more information about this error, try `rustc --explain E0453`.
Reference in New Issue Copy Permalink