mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
610e1a1e05
rust/tests/ui-fulldeps/lint-plugin-forbid-attrs.stderr

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

42 lines
1.3 KiB
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 17:14:38 -06:00
error[E0453]: allow(test_lint) incompatible with previous forbid
--bless ui-fulldeps tests
2019-10-03 02:33:28 -05:00
--> $DIR/lint-plugin-forbid-attrs.rs:11:9
Lint the use of async as an identifier
2018-07-14 09:40:17 -05:00
|
LL | #![forbid(test_lint)]
| --------- `forbid` level set here
...
LL | #[allow(test_lint)]
| ^^^^^^^^^ overruled by previous forbid
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
error: item is named 'lintme'
--bless ui-fulldeps tests
2019-10-03 02:33:28 -05:00
--> $DIR/lint-plugin-forbid-attrs.rs:9:1
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
|
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
LL | fn lintme() {}
| ^^^^^^^^^^^^^^
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
|
Normalise notes with the/is
2020-01-22 17:57:38 -06:00
note: the lint level is defined here
--bless ui-fulldeps tests
2019-10-03 02:33:28 -05:00
--> $DIR/lint-plugin-forbid-attrs.rs:7:11
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | #![forbid(test_lint)]
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
| ^^^^^^^^^
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(test_lint) incompatible with previous forbid
Update tests
2020-01-08 11:02:10 -06:00
--> $DIR/lint-plugin-forbid-attrs.rs:11:9
|
LL | #![forbid(test_lint)]
| --------- `forbid` level set here
...
LL | #[allow(test_lint)]
| ^^^^^^^^^ overruled by previous forbid
Merge `builtins` into `EarlyLintPassObjects`. This avoids calling `early_lint_node` twice. Note: one `early_lint_node` call had `!pre_expansion` for the second argument and the other had `false`. The new single call just has `!pre_expansion`. This results in a reduction of duplicate error messages in some `ui-fulldeps` tests. The order of some `ui-fulldeps` output also changes, but that doesn't matter.
2022-11-30 20:22:08 -06:00
warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/pull/64675
--> $DIR/lint-plugin-forbid-attrs.rs:5:1
|
LL | #![plugin(lint_plugin_test)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: may be removed in a future compiler version
|
= note: `#[warn(deprecated)]` on by default
error: aborting due to 3 previous errors; 1 warning emitted
Do the same things for fulldeps tests
2017-12-10 15:00:10 -06:00
update tests
2018-03-03 08:59:40 -06:00
For more information about this error, try `rustc --explain E0453`.
Reference in New Issue Copy Permalink