Add compiler support for namespaced crates

[b-naber]

Attempt to implement the remaining changes for RFC 3243. This is joint work with @eholk.

Opening a draft PR to get feedback from @petrochenkov on the viability of the approach.

r? @petrochenkov

[b-naber]

Expected this to hold, but it fails when compiling libc. Likely here: https://github.com/rust-lang/libc/blob/e8b01525c30545041af1ad7ba24c05ee3251016b/src/lib.rs#L33-L37

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[petrochenkov]

I've reviewed the implementation, perhaps it can be made a bit differently, but and I don't think it can be made significantly less hacky, so I'm against the direction in general - #122349 (comment).

[b-naber]

I've reviewed the implementation, perhaps it can be made a bit differently, but and I don't think it can be made significantly less hacky, so I'm against the direction in general - #122349 (comment).

Thanks for looking at the PR. I disagree with your conclusion though.

The changes that this PR introduces are fairly isolated from the existing name resolution functionality. We only ever try to resolve to a namespaced crate when try_resolve_ident_in_module fails. If there's a conflict in the sense that my_api exists as a dependency, has a module named utils and a namespaced crate my_api::utils exists at the same time, then the existing conflict detection functionality handles this.

If we do resolve to a namespaced crate it's simply treated as a Module. The current path resolution logic isn't backwards looking; it doesn't matter whether the module path was my_api or my_api::utils when resolving Idents in that Module. So there's essentially no impact here too.

As far as I can tell there's very little maintainability burden introduced by this solution. If there's a large change in the future in terms of how name resolution is supposed to work, I do agree that this is an additional road block that could pose a problem. I kind of imagine that to be manageable, even though it's impossible to tell really without a concrete change in mind. So I can understand you in your wish that this feature wouldn't touch the compiler at all, the fact is that this RFC has already been accepted.

[petrochenkov]

This is a bit similar to cfg(accessible), which seems simple until you actually try to implement it correctly in presence of macro expansion and glob imports, because the definition of "fallback" in name resolution becomes more vague.
I'm going to be skeptical about any proposal involving fallback, unless it can be modeled in terms of the currently used sequences of Scopes.
What this PR does is almost certainly incorrect in general case and not the way to go long term.

the fact is that this RFC has already been accepted.

Until it's stable it can be unaccepted.

While it's unstable I think I'm fine with gradually merging parts that do fit into the current model, and then thinking how to model the remaining parts.
Some parts, e.g. when you cannot have a crate and an organization with the same name, are certainly fine.
(I can think what can be split and merged first, but probably just not right now.)