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

Spurious legacy_derive_helpers lint when unrelated attribute fails to resolve #81871

Closed
Aaron1011 opened this issue Feb 8, 2021 · 4 comments · Fixed by #82419
Closed

Spurious legacy_derive_helpers lint when unrelated attribute fails to resolve #81871

Aaron1011 opened this issue Feb 8, 2021 · 4 comments · Fixed by #82419
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Aaron1011
Copy link
Member

The following code:

// src/lib.rs
use proc_macro::{TokenStream};

#[proc_macro_derive(MyDerive, attributes(my_helper))]
pub fn my_derive(_target: TokenStream) -> TokenStream {
    TokenStream::new()
}


// src/main.rs

#![dummy]

use derive_helper::*;

#[derive(MyDerive)]
#[my_helper]
struct Foo {}

fn main() {}

produces the following errors:

error: cannot find attribute `dummy` in this scope
 --> src/main.rs:1:4
  |
1 | #![dummy]
  |    ^^^^^

error: cannot determine resolution for the attribute macro `derive`
 --> src/main.rs:5:3
  |
5 | #[derive(MyDerive)]
  |   ^^^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

error: cannot determine resolution for the derive macro `MyDerive`
 --> src/main.rs:5:10
  |
5 | #[derive(MyDerive)]
  |          ^^^^^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

error: cannot determine resolution for the attribute macro `my_helper`
 --> src/main.rs:6:3
  |
6 | #[my_helper]
  |   ^^^^^^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

warning: derive helper attribute `my_helper` is used before it is introduced
 --> src/main.rs:6:3
  |
5 | #[derive(MyDerive)]
  |          -------- the attribute is introduced here
6 | #[my_helper]
  |   ^^^^^^^^^
  |
  = note: `#[warn(legacy_derive_helpers)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>

error: aborting due to 4 previous errors; 1 warning emitted

The legacy_derive_helpers warning is spurious and will disappear if #![dummy] is removed.

@Aaron1011 Aaron1011 added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. A-proc-macros Area: Procedural macros labels Feb 8, 2021
@Aaron1011
Copy link
Member Author

Caused by #79078
cc @petrochenkov

@petrochenkov petrochenkov self-assigned this Feb 8, 2021
@estebank estebank added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 8, 2021
@petrochenkov
Copy link
Contributor

This looks like a consequence of #67839.

Initial resolution of derive fails, so it's recovered as an unresolved inert attribute, but due to the linked issue the order of attributes swaps during the "inert attribute expansion".
So we have this code before resolving my_helper:

#[my_helper]
#[derive(MyDerive)]
struct Foo {}

and my_derive gets resolved as a legacy helper.

A fix for #67839 is one of direct follow ups to #79078, so it is in my queue and pretty close to the top.

@petrochenkov
Copy link
Contributor

Copypasting a future test for the ui test suite:

// aux-build:test-macros.rs

#![dummy] //~ ERROR cannot find attribute `dummy` in this scope

#[macro_use]
extern crate test_macros;

#[derive(Empty)] //~ ERROR cannot determine resolution for the attribute macro `derive`
#[empty_helper] //~ WARN derive helper attribute is used before it is introduced
                //~| WARN this was previously accepted
struct Foo {}

fn main() {}

@petrochenkov
Copy link
Contributor

Fixed in #82419.

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 24, 2021
expand: Preserve order of inert attributes during expansion

Fixes rust-lang#67839
Fixes rust-lang#81871
r? `@Aaron1011`
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 24, 2021
expand: Preserve order of inert attributes during expansion

Fixes rust-lang#67839
Fixes rust-lang#81871
r? ``@Aaron1011``
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 26, 2021
expand: Preserve order of inert attributes during expansion

Fixes rust-lang#67839
Fixes rust-lang#81871
r? ```@Aaron1011```
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 27, 2021
expand: Preserve order of inert attributes during expansion

Fixes rust-lang#67839
Fixes rust-lang#81871
r? ````@Aaron1011````
@bors bors closed this as completed in 76b40d2 Feb 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros 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.

3 participants