Skip to content
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

Merged
merged 5 commits into from
Sep 22, 2015
Merged

Conversation

petrochenkov
Copy link
Contributor

Closes #28075
Closes #28388

r? @eddyb
cc @brson

@brson
Copy link
Contributor

brson commented Sep 11, 2015

Awesome fix - look at all that fallout!

@brson brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Sep 11, 2015
identifier: name,
parameters: PathParameters::none()
});
visitor.visit_path(unsafe{&*(&path as *const _)}, id);
Copy link
Contributor

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::{};.

Copy link
Contributor Author

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.

Copy link
Member

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.

@petrochenkov petrochenkov changed the title [WIP] Correctly walk import lists in the default AST visitor Correctly walk import lists in AST visitors Sep 12, 2015
@petrochenkov
Copy link
Contributor Author

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::{};

}
} else {
// FIXME: uncomment this and fix the resulting ICE
// visitor.visit_path(prefix, item.id);
Copy link
Member

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?

Copy link
Contributor Author

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.

@bluss
Copy link
Member

bluss commented Sep 12, 2015

@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
Copy link
Contributor Author

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
Copy link
Contributor Author

Done.

@bors
Copy link
Contributor

bors commented Sep 13, 2015

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

@petrochenkov
Copy link
Contributor Author

Rebased.

@eddyb
Copy link
Member

eddyb commented Sep 14, 2015

@brson Can we get a crater run?

@alexcrichton
Copy link
Member

I've scheduled crater runs.

@alexcrichton
Copy link
Member

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
Copy link
Contributor Author

Updated with a fix for #28388

@bors
Copy link
Contributor

bors commented Sep 16, 2015

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

@petrochenkov
Copy link
Contributor Author

Rebased.

@brson
Copy link
Contributor

brson commented Sep 16, 2015

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

@bors
Copy link
Contributor

bors commented Sep 17, 2015

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

@petrochenkov
Copy link
Contributor Author

Rebased.

@alexcrichton
Copy link
Member

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'
Copy link
Member

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.

@alexcrichton
Copy link
Member

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
Copy link
Contributor Author

@alexcrichton
Tests updated.

@alexcrichton
Copy link
Member

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
Copy link
Contributor

brson commented Sep 21, 2015

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

@alexcrichton
Copy link
Member

@bors: r+ b44cb01

@bors
Copy link
Contributor

bors commented Sep 22, 2015

⌛ Testing commit b44cb01 with merge e9d2587...

bors added a commit that referenced this pull request Sep 22, 2015
@bors bors merged commit b44cb01 into rust-lang:master Sep 22, 2015
@petrochenkov petrochenkov deleted the usegate branch September 23, 2015 12:28
bors added a commit that referenced this pull request Sep 29, 2015
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
@bombless
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants