-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disallow later override of forbid lint in same scope #73379
Disallow later override of forbid lint in same scope #73379
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
The test was mostly artificial and tested behavior of attributes on function parameters rather than semantics of r=me with the nit addressed. |
This comment has been minimized.
This comment has been minimized.
ping @pnkfelix, this needs a rebase |
…ant in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
…nt on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span.
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
45b5f1e
to
4ec4c4f
Compare
@bors r+ |
📌 Commit 4ec4c4f has been approved by |
I think this means the hack in #70918 can now be reverted? |
Ah, that would likely also need a change here: rust/src/librustc_lint/levels.rs Line 89 in 42abbd8
|
self.sess, | ||
src.span(), | ||
E0453, | ||
"{}({}) incompatible with previous forbid in same scope", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, so it is a hard error now to have forbid
and something else on the same scope, but not in a nested scope?
I guess I don't care very strongly, just didn't expect this. I expected the same behavior was for nested scopes. Also I think this is inconsistent with command-line handling (where -F lint -A lint
works, but the -A
has no effect).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand your comment.
It is a hard error, today, to have a forbid on one scope and something else in a nested scope. (AIUI, that's the whole point of forbid, versus deny).
For example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=63cb51c86b8b1c15a8b22f132ce6c32e
Can you show me an example of what current behavior of forbid that you think I should be modelling instead? (In source code, that is; lets leave aside the semantics of command line argument parsing. where I think it is more justifiable to let -F
silently override -A
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, somehow I thought forbid
would overwrite later allow
, I did not know that it makes them an error. Never mind then. I think my only comment for this PR then is that it would be nice to share the code that emits that error -- if the error is pre-existing; the wording is slightly different now.
I feel command-line arguments should be consistent with lint attributes though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with making command line arguments "consistent" with lint attributes, from my point of view, is that I think a lot of tools do inject (or freely mix) new command line arguments, and so I think users run into combinations of -F
and -A
on a single command line a lot more often than they run into #[forbid]
and #[allow]
in a single source item.
A hard error for mixing -F
and -A
when they arose due to e.g. makefile variables is really annoying for end users.
(I suppose the analogy for source code items would be macro expansion, right? Does one see #[allow]
getting injected from macros very often? I can admit this has crossed my mind at times, especially back when I put in the push_unsafe
/pop_unsafe
hacks five years ago ...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed I'd argue that for the same reasons, a hard error could be annoying for the attributes. But then nobody complaining about it for five years is a good argument for it not being very annoying.^^
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
⌛ Testing commit 4ec4c4f with merge fede0bb3089218672644303a714164fd8102a0c0... |
This needs to update the clippy test as well, see https://github.com/rust-lang-ci/rust/runs/1001525771, which is the rollup failure. @bors retry r- |
☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts. |
Closing due to inactivity. |
…w-override-forbid-in-same-scope, r=petrochenkov Disallow overriding forbid in same scope Rebased rust-lang#73379. Fixes rust-lang#70819.
…w-override-forbid-in-same-scope, r=petrochenkov Disallow overriding forbid in same scope Rebased rust-lang#73379. Fixes rust-lang#70819.
Fix #70819
When building lint specs map for a given scope, check if forbid present on each insert.
Drive-by changes:
make
LintLevelsBuilder::push
private to the crate.Add methods to
LintSource
for extracting its name symbol or its span.Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)