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

Renaming builtin attributes does not work, but name resolution thinks it does #79798

Closed
jonas-schievink opened this issue Dec 7, 2020 · 3 comments · Fixed by #80031
Closed
Assignees
Labels
A-attributes Area: #[attributes(..)] A-resolve Area: Path resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jonas-schievink
Copy link
Contributor

Forgive my sins, but:

use allow as deny;

#[deny(unused)]
fn f() {}

The #[deny] still acts as a #[deny], but the import should make it behave like #[allow]. No "unused import" lint is emitted, so name resolution thinks that the import has an effect.

@jonas-schievink jonas-schievink added A-attributes Area: #[attributes(..)] A-resolve Area: Path resolution T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Dec 7, 2020
@petrochenkov
Copy link
Contributor

This should be an error, we have a special check for this in resolve.
I'll check why the error is not reported.

@petrochenkov petrochenkov self-assigned this Dec 7, 2020
@petrochenkov
Copy link
Contributor

Compare with

use global_allocator as allow;

#[allow(unused)]
fn f() {}
error[E0659]: `allow` is ambiguous (built-in attribute vs any other name)
 --> src/lib.rs:3:3
  |
3 | #[allow(unused)]
  |   ^^^^^ ambiguous name
  |
  = note: `allow` could refer to a built-in attribute
note: `allow` could also refer to the attribute macro imported here
 --> src/lib.rs:1:5
  |
1 | use global_allocator as allow;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: use `crate::allow` to refer to this attribute macro unambiguously

Looks like we just consider all (inert) built-in attributes same during this check.

@petrochenkov
Copy link
Contributor

Fixed in #80031.

m-ou-se added a commit to m-ou-se/rust that referenced this issue Jan 16, 2021
resolve: Reject ambiguity built-in attr vs different built-in attr

Fixes rust-lang#79798.

Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
m-ou-se added a commit to m-ou-se/rust that referenced this issue Jan 17, 2021
resolve: Reject ambiguity built-in attr vs different built-in attr

Fixes rust-lang#79798.

Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
@bors bors closed this as completed in 3d5e7e0 Jan 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: #[attributes(..)] A-resolve Area: Path resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants