Correctly walk import lists in AST visitors

[petrochenkov]

Closes #28075
Closes #28388

r? @eddyb
cc @brson

[brson]

Awesome fix - look at all that fallout!

[eefriedman]

visit_path is defined as fn visit_path(&mut self, path: &'v Path, _id: NodeId) {, i.e. the lifetime of the path is tied to the the lifetime of the visitor, not the lifetime of the callback. Also, the current PR visits both the path's components and the path as a whole. Also, cloning the prefix is a bunch of extra computation which is unlikely to be useful

Probably the most straightforward thing to do would be to add a method visit_path_list_item(&mut self, prefix: &'v Path, item: &'v PathListItem) to Visitor and let the callee do the right thing.

Related issue: we probably also want a method on Visitor to visit the prefix; it would be useful for fixing the handling of use std::foobar::{};.

[petrochenkov]

Yes, the prefix is cloned and components of the prefix are visited repeatedly. I supposed this couldn't be done optimally without introducing a new visit_xxx method, but introducing it seemed.. intrusive and too far away from stability.rs. I'll surely do it if it's acceptable.

I also had an idea to desugar use a::{b, c}; into use a::b; use a::b; during lowering to HIR, it would avoid repeated cloning of the prefix, but checks of the prefix components would still be duplicated.

[eddyb]

The way the visitor is designed is so that certain visitors can "opt in" to observe the original AST/HIR lifetime and be able to hold onto those references.
Unsafe code here is just wrong.
You have two options: if the HIR map builder doesn't override this particular method, you can drop the lifetime.
Otherwise, you'll have go the explicit route @eefriedman mentioned, with one extra tip: you can always write some sort of iterator for the expansions.

[petrochenkov]

Updated with accordance to the @eefriedman 's advice and rebased.
I'm going to seat on this patch a bit more and fix another bug similar to #28075, allowing unstable items outside of braces in imports like

use std::rt::{};

[eddyb]

Where does the ICE come from?

[petrochenkov]

Privacy checker. It assumes the prefix is not empty.

[bluss]

@brson This bug was discovered when we removed a gated function. With this fix, we add new breaking changes by disallowing imports of still present, unused, unstable functionality. Maybe it deserves a crater run? If the fallout is bad, maybe even a warning cycle (even if that sounds extreme).

[petrochenkov]

I'm going to seat on this patch a bit more and fix another bug similar to #28075, allowing unstable items outside of braces in imports like use std::rt::{};

So, fixing this issue would likely require going to librustc_resolve, resolving the prefix and assigning PathResolution to it without actually importing std::rt in the process. I'm not familiar with resolve, so I'm just going to fill a new issue and leave it for later. Update for this PR will follow soon either.

[petrochenkov]

Done.

[bors]

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

[petrochenkov]

Rebased.

[eddyb]

@brson Can we get a crater run?

[alexcrichton]

I've scheduled crater runs.

[alexcrichton]

Looks like this has some relatively significant breakage.

The cause of all the root regressions appears to be that we have an unstable std::intrinsics module, but stable contents (because they're reexported). It was assumed that use std::intrinsics would be guarded, but this bug let it slide, so all these use cases got pass the feature gater.

I would personally think, however, that we could submit PRs to update all those crates, rebuild the other non-root-regressions to make sure there's no more fallout, and then land this while publishing information about how to migrate. The breakage here may be largely limited to the std::intrinsics module, so it may not be that bad.

thoughts @brson?

[petrochenkov]

Updated with a fix for #28388

[bors]

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

[petrochenkov]

Rebased.

[brson]

Yeah, let's submit PR's downstream. I can look into it tomorrow.

[bors]

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

[petrochenkov]

Rebased.

[alexcrichton]

I have submitted PRs upstream to affected crates:

• rust-compress
• tendril
• gfx

[alexcrichton]

Can you tweak this test to use an aux-build with an unstable module instead? This module in theory may be removed over time.

[alexcrichton]

Similarly to down below, can you make an auxiliary file for this instead of relying on particular features in the standard library being unstable? (these will change over time)

[alexcrichton]

Once those PRs have been merged/released I think we'll want to do another crater run here now that more bugs have been fixed.

[petrochenkov]

@alexcrichton
Tests updated.

[alexcrichton]

Ok, a new crater run indicates that this has 4 root regressions, 2 of which were spurious because of timeouts and 2 of which were because libraries are depending on an older version of gfx which did not get the fix in gfx-rs/gfx#803.

@brson, how do you feel about merging? I'm comfortable with the breakage here and I think we may want to make a post on internals and such to ensure that everyone knows about this, but I think this should be good to go.

[brson]

@alexcrichton Yes, I feel ok about it. Thanks for doing the downstream work.

[alexcrichton]

@bors: r+ b44cb01

[bors]

⌛️ Testing commit b44cb01 with merge e9d2587...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[bombless]

mod some_module {
    enum _Enum { A, B, _Dummy }
    pub type Enum = self::_Enum;
    pub use self::_Enum::{A, B};
}
fn to_string(e: some_module::Enum) -> String {
    match e {
        some_module::A => 'A'.to_string(),
        some_module::B => 'B'.to_string(),
        _ => "_not_supported".to_string()
    }
}

We might need to apply the privacy rule to type as well .

EDIT: I checked the PR again and find that above problem is sort of unrelated.