Unexpected "macro is ambiguous" error when macro imports are generated by a macro

[RalfJung]

This code compiles just fine, as one would expect:

macro_rules! assert_biteq_rt {
    ($left:expr, $right:expr $(,)?) => {};
}
macro_rules! assert_biteq_const {
    ($left:expr, $right:expr $(,)?) => {};
}

// Use the runtime version by default.
// This way, they can be shadowed by the const versions.
pub(crate) use assert_biteq_rt as assert_biteq;

// Also make the const version available for re-exports.
pub(crate) use assert_biteq_const;

mod something_nomacro {
    use super::*;

    mod const_ {
        use super::*;
        use crate::assert_biteq_const as assert_biteq;
        
        #[test]
        pub fn test() {
            const { assert_biteq!(0, 0); }
        }
    }
}

However, if I write a macro to generate the actual module at the end that contains the test...

macro_rules! float_test {
    (
        name: $name:ident,
        test $test:block
    ) => {
        mod $name {
            use super::*;
            
            mod const_ {
                use super::*;
                use crate::assert_biteq_const as assert_biteq;
                
                #[test]
                fn test() {
                    const { $test }
                }
            }
        }
    }
}

float_test! {
    name: something_macro,
    test {
        assert_biteq!(0, 0);
    }
}

... then it stops compiling:

error[E0659]: `assert_biteq` is ambiguous
  --> src/lib.rs:53:9
   |
53 |         assert_biteq!(0, 0);
   |         ^^^^^^^^^^^^ ambiguous name
   |
   = note: ambiguous because of a conflict between a name from a glob import and a macro-expanded name in the same module during import or macro resolution
note: `assert_biteq` could refer to the macro imported here
  --> src/lib.rs:39:21
   |
39 |                   use crate::assert_biteq_const as assert_biteq;
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
50 | / float_test! {
51 | |     name: something_macro,
52 | |     test {
53 | |         assert_biteq!(0, 0);
54 | |     }
55 | | }
   | |_- in this macro invocation
   = help: use `self::assert_biteq` to refer to this macro unambiguously
note: `assert_biteq` could also refer to the macro imported here
  --> src/lib.rs:38:21
   |
38 |                   use super::*;
   |                       ^^^^^^^^
...
50 | / float_test! {
51 | |     name: something_macro,
52 | |     test {
53 | |         assert_biteq!(0, 0);
54 | |     }
55 | | }
   | |_- in this macro invocation
   = help: consider adding an explicit import of `assert_biteq` to disambiguate

The error helpfully tells me to add an explicit import, but I already did that.

This is a minimized version of real code from the libcore test suite. The only way I found so far to avoid this problem is to avoid use super::*; inside mod const_ and instead manually re-import everything we need. That's quite annoying as it means every time we add a new top-level import, we have to remember to also import it inside mod const_ or else the macro-generated tests will start failing.

Cc @petrochenkov in the hopes that you have an idea of what is going on. It is quite puzzling to me that manually expanding the float_test! macro makes the error go away...

[RalfJung]

The same kind of shadowing trick works entirely fine for non-macro items:

fn assert_biteq_rt() {}
const fn assert_biteq_const() {}

// Use the runtime version by default.
// This way, they can be shadowed by the const versions.
pub(crate) use assert_biteq_rt as assert_biteq;

macro_rules! float_test {
    (
        name: $name:ident,
        test $test:block
    ) => {
        mod $name {
            use super::*;
            
            mod const_ {
                use super::*;
                use crate::assert_biteq_const as assert_biteq;
                
                #[test]
                fn test() {
                    const { $test }
                }
            }
        }
    }
}

float_test! {
    name: something_macro,
    test {
        assert_biteq();
    }
}

[eggyal]

Hygiene ensures that the assert_biteq in use crate::assert_biteq_const as assert_biteq is a different identifier to that in $test. You will need to pass assert_biteq as an ident from the invocation into the definition so that the import can be defined as use crate::assert_biteq_const as $whatever.

(Written before I saw your second comment).

[RalfJung]

Hygiene usually only applies to local (let-bound) variables, not items. Sometimes that's a bug, here we use it as a feature to be able to write code once and then run it both inside and outside const blocks.

[petrochenkov]

This is the relevant logic:

rust/compiler/rustc_resolve/src/ident.rs

Lines 839 to 848 in f824853

	} else if innermost_decl.expansion != LocalExpnId::ROOT
	&& (!module_only || ns == MacroNS)
	&& let Scope::ModuleGlobs(m1, _) = scope
	&& let Scope::ModuleNonGlobs(m2, _) = innermost_scope
	&& m1 == m2
	{
	// FIXME: this error is too conservative and technically unnecessary now when module
	// scope is split into two scopes, at least when not resolving in `ScopeSet::Module`,
	// remove it with lang team approval.
	Some(AmbiguityKind::GlobVsExpanded)

[petrochenkov]

The expansion != ROOT logic in particular makes it too conservative.
If the snippet above doesn't also trigger the may_appear_after logic slightly above, then it should start compiling once the FIXME is addressed.

[RalfJung]

I guess the ns == MacroNS there is why this error occurs for macros but not other items?

remove it with lang team approval

Is there an existing issue tracking this -- describing what this means on the language level so it can be brought to the team?

[petrochenkov]

No tracking issues, only FIXMEs in code.
There are 2-3 similar rule relaxations that were unlocked by #149681 and #144793.
I wanted to take them all together and make a lang team proposal.