Repository navigation
Running cargo test with proc macro that uses main fails #62127
Description
Activity
Built-in attribute
#[x]will conflict with any other attribute namedxin 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.I wasn't aware, but is there
mainattribute 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
I wasn't aware, but is there
mainattribute which used by compiler already?Yes, it turns an arbitrary function into
main.#![feature(main)] #[main] fn not_named_main() { println!("Hello"); } --- Output Hello
@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@DoumanAsh
Only single-segment paths are ambiguous, an attribute macro namedmaincan 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() {}
Ah but in my doctest it was
#[tokio_macros::main]and it fails?
So I assume byOkyou mean how it is supposed to be?I suspect that
#[tokio_macros::main]is irrelevant and the ambiguous#[main]is generated by the test harness, so this minimized example should also fail:/// ``` /// fn main() {} /// ``` #[proc_macro_attribute] pub fn main(args: TokenStream, item: TokenStream) -> TokenStream { item }
Yes, you are right, it seems the problem is with using
mainas name of attribute to define rather than with doc test itself@rustbot assign @petrochenkov
Not a regression, the issue reproduces on Rust 1.30 already (the release that stabilized procedural macro attributes).
Minimized example:
// rustc --test #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro_attribute] pub fn main(args: TokenStream, item: TokenStream) -> TokenStream { item }
As described above, the behavior is expected - the test harness uses the built-in
#[main]attribute which becomes ambiguous if any other attribute namedmainis in scope.- added a commit that references this issue
on May 24, 2020
Attempting to run test with proc macro that uses
mainas identifier fails with following error: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)tooUPD 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: