-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly walk import lists in AST visitors #28364
Conversation
Awesome fix - look at all that fallout! |
identifier: name, | ||
parameters: PathParameters::none() | ||
}); | ||
visitor.visit_path(unsafe{&*(&path as *const _)}, id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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::{};
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
8f62647
to
ac660cd
Compare
Updated with accordance to the @eefriedman 's advice and rebased.
|
} | ||
} else { | ||
// FIXME: uncomment this and fix the resulting ICE | ||
// visitor.visit_path(prefix, item.id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the ICE come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Privacy checker. It assumes the prefix is not empty.
@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). |
So, fixing this issue would likely require going to librustc_resolve, resolving the prefix and assigning |
Done. |
☔ The latest upstream changes (presumably #28339) made this pull request unmergeable. Please resolve the merge conflicts. |
a57386c
to
a69a520
Compare
Rebased. |
@brson Can we get a crater run? |
I've scheduled crater runs. |
Looks like this has some relatively significant breakage. The cause of all the root regressions appears to be that we have an unstable 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 thoughts @brson? |
a69a520
to
d60c936
Compare
Updated with a fix for #28388 |
☔ The latest upstream changes (presumably #28399) made this pull request unmergeable. Please resolve the merge conflicts. |
d60c936
to
355daea
Compare
Rebased. |
Yeah, let's submit PR's downstream. I can look into it tomorrow. |
☔ The latest upstream changes (presumably #28349) made this pull request unmergeable. Please resolve the merge conflicts. |
355daea
to
1599c16
Compare
Rebased. |
I have submitted PRs upstream to affected crates: |
|
||
// Prefix in imports with empty braces should be resolved and checked privacy, stability, etc. | ||
|
||
use std::rt::{}; //~ ERROR use of unstable library feature 'rt' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you tweak this test to use an aux-build
with an unstable module instead? This module in theory may be removed over time.
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. |
@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. |
@alexcrichton Yes, I feel ok about it. Thanks for doing the downstream work. |
Some minor parts of AST and HIR were not visited by the `visit::walk_xxx` methods - some identifiers, lifetimes, loop labels, attributes of exported macros - but nothing as serious as in, for example, #28364. \+ Added a convenience macro for visiting lists (including Options) \+ Removed some pre-Deref-coersions `&**` noise from visitors r? @nrc
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 EDIT: I checked the PR again and find that above problem is sort of unrelated. |
Closes #28075
Closes #28388
r? @eddyb
cc @brson