resolve: Report more visibility-related early resolution ambiguities for imports

[petrochenkov]

The new ambiguities are reported when the import's visibility is ambiguous and may depend on the resolution/expansion order.

Detailed description: #149596 (comment).

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
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]

@bors try

[petrochenkov]

@craterbot run mode=check-only p=1 crates=https://crater-reports.s3.amazonaws.com/pr-149145/retry-regressed-list.txt

[rust-bors]

☀️ Try build successful (CI)
Build commit: ce3348c (ce3348c21531b911ca5aadbbbe7ad63a1bc4c382, parent: 8202d110516c6bd87cee375e9a9b774db499015c)

[petrochenkov]

@craterbot run mode=check-only p=1 crates=https://crater-reports.s3.amazonaws.com/pr-149145/retry-regressed-list.txt

[craterbot]

👌 Experiment pr-149596 created and queued.
🤖 Automatically detected try build ce3348c
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-149596 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-149596 is completed!
📊 359 regressed and 0 fixed (3583 total)
📊 218 spurious results on the retry-regessed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-149596/retry-regressed-list.txt ↩

[petrochenkov]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: e617cc9 (e617cc9342f64b2efdd8eeb91834ef450a15825f, parent: 29e035e1728488dce5a03daa527ab1091d1cda47)

[petrochenkov]

ping @joshtriplett @nikomatsakis @scottmcm
This is now the only thing blocking parallel import resolution (#145108).

[joshtriplett]

Checking a box on this.

Separately, I'm looking forward to the future edition changes proposed in #148610 to simplify pub use of macros, and hopefully eventually allow pub macro_rules! ....

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

@rfcbot reviewed

I was reluctant to check my box here but I've become convinced that the current behavior is nice in its own way and that changing it in the way I proposed might cause private APIs to become "accidentally" exposed. The example that @tmandry showed me, which I believe came from @Nadrieril, is:

mod internal {
  mod inner {
    pub struct Foo;
  }
  pub(crate) use inner::Foo;
  pub struct Bar;
}
pub use internal::*; // `Foo` would now be part of the public API of the crate

Here, here the intent of the inner module is not to think about visibility at all, and to have the visibility defined in the pub-use re-exports from the internal module.

Put another way: what I consider most important is "locality of reasoning" about visibility. I want to be able to look at a particular declaration and understand who might be relying on it. And I can see that the model I proposed in fact violates that locality of reasoning in an example like this. Not for the inner module but for the internal module, where the pub(crate) use inner::Foo in fact exposes something publicly but only due to "action at a distance" from a pub-use in the root crate. This is exactly the kind of thing we wanted to avoid by requiring you to put pub on items that may be exported publicly from your crate by other pub use statements.

So, I'm convinced. Thanks all for the discussion. I think it'd be useful to try and capture these notes somewhere for the next time I am confused.

[yaahc]

Is it possible to invoke this error without involving macros at all? I'm guessing it isn't and that it depends on macro_use to even be able to legally import the same item twice into the same scope with different visibility without running afoul of the "multiple decls for the same ident" error or just straight up shadowing if one import is a glob. If it is possible however I'd like to see an associated test case added.

View changes since this review

[petrochenkov]

Is it possible to invoke this error without involving macros at all?

Probably, in the GlobVsOuter case?
Also I'll extend the lint to GlobVsGlob cases in a later PR (#149596 (comment)).

[yaahc]

lgtm, will r+ once the fcp completes and conflicts are resolved

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[petrochenkov]

@bors r=yaahc

[rust-bors]

📋 This PR cannot be approved because it currently has the following label: S-waiting-on-fcp.

[petrochenkov]

@bors r=yaahc

[rust-bors]

📌 Commit e7245c2 has been approved by yaahc

It is now in the queue for this repository.