Running cargo test with proc macro that uses main fails

[DoumanAsh]

Attempting to run test with proc macro that uses main as identifier fails with following error:

error[E0659]: `main` is ambiguous (built-in attribute vs any other name)
  |
  = note: `main` could refer to a built-in attribute
note: `main` could also refer to the crate-local procedural macro defined here
 --> tokio-macros\src\lib.rs:26:1
  |
26| / pub fn main(args: TokenStream, item: TokenStream) -> TokenStream {
27| |     let input = syn::parse_macro_input!(item as syn::ItemFn);
28| |
29| |     let ret = &input.decl.output;
... |
41| |     result.into()
42| | }
  | |_^
  = help: use `crate::main` to refer to this crate-local procedural macro unambiguously

Rustc version:rustc 1.37.0-nightly (8aa42ed7c 2019-06-24)

But it seems it wasn't present in rustc 1.35.0 (3c235d560 2019-05-20)

UPD: It is present since (400b409ef 2019-06-09) too

UPD 2: Might be always present as cargo test seems to inject own main

So something changed in the way such identifier is treated.

Code example:

/// ```
/// #[tokio_macros::main]
/// fn main() {
///     println!("Hello world");
/// }
/// ```
#[proc_macro_attribute]
pub fn main(args: TokenStream, item: TokenStream) -> TokenStream {
    let input = syn::parse_macro_input!(item as syn::ItemFn);

    let ret = &input.decl.output;
    let name = &input.ident;
    let body = &input.block;
    let attrs = &input.attrs;

    let result = quote! {
        #(#attrs)*
        fn #name() #ret {
            #body
        }
    };

    result.into()
}

[Centril]

cc @petrochenkov

[petrochenkov]

Built-in attribute #[x] will conflict with any other attribute named x in scope due to issues that are hard to fix.
This rule was in effect since macro modularization and stabilization of attribute macros.

So, the regression here is that something injects a use of built-in attribute #[main] where it wasn't used previously.
This may be an acceptable regression though, since it's equivalent to introducing a new built-in attribute and we are probably not going to stop introducing new built-in attributes.

[DoumanAsh]

I wasn't aware, but is there main attribute which used by compiler already?

But I see the problem with name resolution despite using absolute path, if it is difficult/impossible to resolve it is not really critical

[petrochenkov]

@DoumanAsh

I wasn't aware, but is there main attribute which used by compiler already?

Yes, it turns an arbitrary function into main.

#![feature(main)]

#[main]
fn not_named_main() {
    println!("Hello");
}

--- Output

Hello

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e53c20462ac85fb770709af2551bde4f

[DoumanAsh]

@petrochenkov So does the issue boils down to resolution of attribute then?
Or should any usage of builtin attribute fail regardless of used path to access it

[petrochenkov]

@DoumanAsh
Only single-segment paths are ambiguous, an attribute macro named main can still be used if it's referred to by a module-relative path or renamed.

// Ok.
 #[tokio_macros::main]
fn foo() {}

// Ok.
use tokio_macros::main as pain;
#[pain]
fn foo() {}

// Not Ok, ambiguity.
use tokio_macros::main;
#[main]
fn foo() {}

[DoumanAsh]

Ah but in my doctest it was #[tokio_macros::main] and it fails?
So I assume by Ok you mean how it is supposed to be?