Resolve: allow non-imported items to shadow glob imports

[jseyfried]

This PR lets non-imported items shadow glob imported items (fixes #31337).
More precisely, a glob imported item will be shadowed (in all of the namespaces it defines) if any namespace it defines is already defined by a non-imported item.

Previously, it was possible to shadow only one namespace of a glob-imported re-export that defined both namespaces, so this is a [breaking-chage]. For example,

mod foo {
    mod bar { pub struct Bar; }
    pub use self::bar::Bar;
}

pub use foo::*; // This imports the item `foo::bar::Bar`.

// The following used to only shadow `Bar` in the value namespace,
// leaving `foo::bar::Bar` only partially accessible.
// Now, it shadows `Bar` in both namespaces.
pub fn Bar() {}

fn f() -> Bar { foo::Bar } // This breaks

The breakage can be fixed by importing the shadowed item again as a fresh name or by renaming the item that shadows it.
r? @nrc

[nrc]

I think we want an RFC before accepting this, right? (As discussed in #31337)

[bors]

☔️ The latest upstream changes (presumably #31338) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

Could you add a comment describing the purpose of this flag?

[jseyfried]

Done

[petrochenkov]

This test ensures that variants are defined in both namespaces, it shouldn't be deleted, it should be tweaked to avoid glob imports instead.
pub use variant_namespacing::XE::* -> pub use variant_namespacing::XE::{XStruct, XTuple, XUnit} etc.

[jseyfried]

Good point, I added it back with your tweak.

[petrochenkov]

So, reexport sets are free from name conflicts now and #31308 can be landed?

[jseyfried]

Indeed :)

[petrochenkov]

Are "glob vs glob" conflicts still result in errors? (In this implementation, I mean, not in the potential RFC.)

[jseyfried]

@petrochenkov yes -- glob vs glob conflicts are still errors, as are glob import vs single import conflicts.

[bors]

☔️ The latest upstream changes (presumably #31461) made this pull request unmergeable. Please resolve the merge conflicts.

[jseyfried]

rebased

[nikomatsakis]

We discussed this in the recent @rust-lang/lang meeting. Our conclusion was that the correct semantics is not entirely clear here. @nrc is planning on introducing an RFC describing the name resolution system soon -- one that will also incorporate changes to hygiene and macro expansion -- and plans to raise this issue in that RFC. So we figured it'd be best to wait on making an official decision until we have time to discuss the alternatives in that forum.

[bors]

☔️ The latest upstream changes (presumably #31648) made this pull request unmergeable. Please resolve the merge conflicts.

[jseyfried]

Closing because of the decision in #31337 and because I no longer like the "linked namespaces" shadowing sematics I implemented here (see this comment).