resolve: Mark items under exported ambiguous imports as exported

[petrochenkov]

After #147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint.

So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc.
The added test shows an example.
This fixes around 10-20 crater regressions found in #149195 (comment).

Unblocks #149195.

[rustbot]

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

• It's intentional.
• The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

[rustbot]

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[petrochenkov]

cc @obi1kenobi #149195 (comment)

From the cargo-semver-checks's point of view introducing a public name through an ambiguous reexport is clearly a breaking change, even if it technically can be allowed (and is allowed implicitly in dependencies).
Cases like that are actually reported by rustc using another lint called ambiguous_glob_reexports (regular, not future-compatibility).

Not marking items accessible through ambiguous imports as exported can cause errors like "missing optimized MIR" or linking errors, but I'm not sure if it can cause ICEs.
Reporting errors like that instead of ambiguous_glob_imports would probably be okay for directly compiled crates because they already produce an error (the lint is deny-by-default), but is not so good for ambiguous glob imports in dependencies because unlike lints such errors cannot be capped and break all other crates depending on the crate using them.

[obi1kenobi]

Thanks for the tag. I read the contents of this PR and also the description at #147984 (comment) and I still have a few questions.

#147984 (comment) mentioned the desire to make both local and cross-crate ambiguous errors behave consistently, which makes sense to me. But is that change limited solely to improving errors only? Or is it possible that a Rust program that previously would have failed to compile now is able to compile without errors, even if some lints had to be allowed?

cargo-semver-checks currently treats ambiguity as "attempting to use either item is an error." I'm attempting to determine if that's ever not correct, including with lints, so we can raise the right diagnostic with full and accurate info.

Right now I'm worried that I don't know how to model the case of "one of the items is made available but it isn't defined which one".

[petrochenkov]

Right now I'm worried that I don't know how to model the case of "one of the items is made available but it isn't defined which one".

That's the main problem, the compiler cannot define it either - it depends on internal unstable details that we don't want to expose, like specific expansion and import resolution order.
Otherwise this wouldn't be an error or future error.

If this is reported as a deprecation lint and not an error, the specific compiler's choice can be visible from the the effective visibility tables - the chosen alternative will be marked as exported, and the other alternatives will not.

Or is it possible that a Rust program that previously would have failed to compile now is able to compile without errors, even if some lints had to be allowed?

It's a language change, not just diagnostics, more names appear in modules and they may cause more names to appear in other modules through imports, and may cause more name conflicts.

In case of glob conflicts new programs will be able to compile under deprecation lints, some programs that previously compiled will report deprecation lints and will stop compiling in the future, in corner cases some compiling programs even start reporting hard errors like in the examples from #147984 (comment).
It probably cannot make previously erroneous programs compile without deprecation lints.