Skip to content
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

Conversation

pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Jun 15, 2020

Fix #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...)

@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 15, 2020
@pnkfelix pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 16, 2020
@petrochenkov
Copy link
Contributor

Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...

The test was mostly artificial and tested behavior of attributes on function parameters rather than semantics of forbid.
It should probably be ok to defer crater checking to the regular beta run.

r=me with the nit addressed.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 16, 2020
@bors

This comment has been minimized.

@Muirrum Muirrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 16, 2020
@petrochenkov
Copy link
Contributor

ping @pnkfelix, this needs a rebase

@Muirrum Muirrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 13, 2020
pnkfelix and others added 4 commits August 17, 2020 23:24
…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>
@pnkfelix pnkfelix force-pushed the issue-70819-disallow-override-forbid-in-same-scope branch from 45b5f1e to 4ec4c4f Compare August 18, 2020 05:24
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Aug 18, 2020

📌 Commit 4ec4c4f has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 18, 2020
@RalfJung
Copy link
Member

I think this means the hack in #70918 can now be reverted?

@RalfJung
Copy link
Member

RalfJung commented Aug 18, 2020

Ah, that would likely also need a change here:

specs.insert(id, (level, src));

self.sess,
src.span(),
E0453,
"{}({}) incompatible with previous forbid in same scope",
Copy link
Member

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).

Copy link
Member Author

@pnkfelix pnkfelix Aug 18, 2020

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.)

Copy link
Member

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.

Copy link
Member Author

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 ...)

Copy link
Member

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.^^

tmandry added a commit to tmandry/rust that referenced this pull request Aug 18, 2020
…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...)
tmandry added a commit to tmandry/rust that referenced this pull request Aug 19, 2020
…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...)
tmandry added a commit to tmandry/rust that referenced this pull request Aug 19, 2020
…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...)
@bors
Copy link
Contributor

bors commented Aug 19, 2020

⌛ Testing commit 4ec4c4f with merge fede0bb3089218672644303a714164fd8102a0c0...

@JohnTitor
Copy link
Member

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-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 19, 2020
@bors
Copy link
Contributor

bors commented Aug 30, 2020

☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts.

@crlf0710 crlf0710 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 18, 2020
@petrochenkov
Copy link
Contributor

Closing due to inactivity.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 6, 2020
…w-override-forbid-in-same-scope, r=petrochenkov

Disallow overriding forbid in same scope

Rebased rust-lang#73379.

Fixes rust-lang#70819.
flip1995 pushed a commit to flip1995/rust that referenced this pull request Oct 9, 2020
…w-override-forbid-in-same-scope, r=petrochenkov

Disallow overriding forbid in same scope

Rebased rust-lang#73379.

Fixes rust-lang#70819.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

forbid overwritten by later allow on the same "scope level"
8 participants