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

Improve allowness of the unexpected_cfgs lint #94433

Merged
merged 1 commit into from
Mar 3, 2022

Conversation

Urgau
Copy link
Member

@Urgau Urgau commented Feb 27, 2022

This pull-request improve the allowness (#[allow(...)]) of the unexpected_cfgs lint.

Before this PR only crate level #![allow(unexpected_cfgs)] worked, now with this PR it also work when put around cfg! or if it is in a upper level. Making it work for the attributes cfg, cfg_attr, ... for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on #94298.
r? @petrochenkov

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 27, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 27, 2022
compiler/rustc_expand/src/config.rs Outdated Show resolved Hide resolved
compiler/rustc_attr/src/builtin.rs Outdated Show resolved Hide resolved
@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 Feb 28, 2022
@Urgau
Copy link
Member Author

Urgau commented Feb 28, 2022

Address review comments.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 28, 2022
@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 Mar 1, 2022
@Urgau
Copy link
Member Author

Urgau commented Mar 1, 2022

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 1, 2022
@petrochenkov
Copy link
Contributor

Thanks!
@bors r+

@bors
Copy link
Contributor

bors commented Mar 1, 2022

📌 Commit 765205b 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-review Status: Awaiting review from the assignee but also interested parties. labels Mar 1, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 1, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? `@petrochenkov`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ``@petrochenkov``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ```@petrochenkov```
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ````@petrochenkov````
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? `````@petrochenkov`````
@Urgau Urgau mentioned this pull request Mar 2, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ``````@petrochenkov``````
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ```````@petrochenkov```````
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 3, 2022
Rollup of 9 pull requests

Successful merges:

 - rust-lang#92061 (update char signess for openbsd)
 - rust-lang#93072 (Compatible variants suggestion with desugaring)
 - rust-lang#93354 (Add documentation about `BorrowedFd::to_owned`.)
 - rust-lang#93663 (Rename `BorrowedFd::borrow_raw_fd` to `BorrowedFd::borrow_raw`.)
 - rust-lang#94375 (Adt copy suggestions)
 - rust-lang#94433 (Improve allowness of the unexpected_cfgs lint)
 - rust-lang#94499 (Documentation was missed when demoting Windows XP to no_std only)
 - rust-lang#94505 (Restore the local filter on mono item sorting)
 - rust-lang#94529 (Unused doc comments blocks)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 493ed7a into rust-lang:master Mar 3, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 3, 2022
@Urgau Urgau deleted the check-cfg-allowness branch May 5, 2023 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

5 participants