macro definition can cause modules to become undefined in certain situations

[KristofferC]

Reduced from https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/c78016e_vs_d63aded/DataToolkitCommon.primary.log

module M
module I
    using ..M # comment out -> works
    macro m()
        :(a = Base.x) # remove `Base` -> works
    end
end

using .I # comment out -> works
function f()
    I.@m()
end

Base

end

now causes

ERROR: UndefVarError: `Base` not defined in `Main.M`
Hint: It looks like two or more modules export different bindings with this name, resulting in ambiguity. Try explicitly importing it from a particular module, or qualifying the name with the module it should come from.
Hint: a global variable of this name also exists in Base.

[Keno]

There's two issues here. One is an issue with the treatment of circular imports. The other is that after the export partitioning, we try to looks through the binding even though it's not exported (because we can't ask about it being exported until we've resolved the partition). I'll work on a fix. The macro piece is largely unrelated and just causes the queries to happen in the right order

[Keno]

Actually maybe three issues. The world. bounds on the circular imports are also not correct

[Keno]

Ok, one more missing puzzle piece that was bugging me. This was not reproducing with simpler reproducers, because we have a fast path that skips considering bindings if nobody has looked at them, so we needed some code path to look at the binding I.Base, but not resolve it. There's not that much code that does things like that, but some parts of lowering and inference do. Simpler reproducer:

module M
module I
    using ..M
end
using .I
convert(Core.Binding, GlobalRef(I, :Base))
Base
end