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

resolve: More groundwork for item_like_imports (RFC 1560) #35776

Merged
merged 18 commits into from
Aug 21, 2016

Conversation

jseyfried
Copy link
Contributor

r? @nrc

@jseyfried
Copy link
Contributor Author

jseyfried commented Aug 18, 2016

cc #35120 (tracking issue for RFC 1560)
cc @petrochenkov

@jseyfried
Copy link
Contributor Author

RFC 1560's diagnostics and corner cases (esp. w.r.t. ambiguous bindings) ended up being a bit trickier to implement than I expected (my prototype, #32213, cut some corners semantically).

That being said, I believe this will be the final groundwork PR -- once this lands, #[feature(item_like_imports)] should be doable in a single PR.

} else {
// `resolve_name_in_module` reported a privacy error.
self.import_dummy_binding(directive);
Success(())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error reporting system is correct but (imo) ugly.

After finishing #[feature(item_like_imports)], I plan on adding a name resolution error type (more expressive than today's (Span, String)) which will be able to represent privacy errors and ambiguity errors as well as arbitrary (Span, String) errors.

@nrc
Copy link
Member

nrc commented Aug 18, 2016

Question about the current_vis commit: why do you track this in resolve? Is it needed in resolve, or is it just to have that info for privacy checking?

type_determined: Cell<bool>,
value_determined: Cell<bool>,
value_result: Cell<Result<&'a NameBinding<'a>, bool /* determined? */>>,
type_result: Cell<Result<&'a NameBinding<'a>, bool /* determined? */>>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use an enum instead of these bools?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@nrc
Copy link
Member

nrc commented Aug 18, 2016

Looks good! A few comments inline, I guess I'm a bit uneasy about moving some of the privacy checking into resolution, but we do some already. Do you think it would be possible to separate further rather than merging? Or is that a dream?

@jseyfried
Copy link
Contributor Author

jseyfried commented Aug 18, 2016

I believe we need to perform at least some privacy checking in resolve. For example,

mod foo {
    pub mod bar {}
    pub(some::path) fn bar() { println!("1"); }
}
mod baz {
    pub fn bar() { println!("2"); }
}
fn main() {
    use foo::bar; // Whether this imports the value depends on accessibility.
    use baz::*;
    bar(); // If `pub(some::path)` items are accessible here, this is "1"; otherwise, it is "2".
}

@jseyfried
Copy link
Contributor Author

current_vis is convenient but not necessary -- it is always just

ty::Visibility::Restricted({
    let normal_module = self.get_nearest_normal_module_parent_or_self(module);
    self.definitions.as_local_node_id(normal_module.def_id().unwrap()).unwrap()
})

This PR uses it outside of just privacy checking to deduce import resolution failure. For example,

mod foo {
    use bar::f::*; // (1) Since this is not accessible in bar,
    // (4) ^ Thus we are able to resolve this import.
    pub fn f() {}
}
mod bar {
    pub use foo::f; // (2) we can deduce that this fails in the type namespace,
    pub use baz::*; // (3) so we know that `bar::f` will resolve to `baz::f` since it won't get shadowed.
}
mod baz {
    pub mod f {}
}

Without being able to deduce (2), this example would deadlock (note that it works today).

@nrc
Copy link
Member

nrc commented Aug 19, 2016

@bors: r+

@bors
Copy link
Contributor

bors commented Aug 19, 2016

📌 Commit a6e8f3b has been approved by nrc

bors added a commit that referenced this pull request Aug 21, 2016
resolve: More groundwork for `item_like_imports` (RFC 1560)

r? @nrc
@bors
Copy link
Contributor

bors commented Aug 21, 2016

⌛ Testing commit a6e8f3b with merge 1576de0...

@bors bors merged commit a6e8f3b into rust-lang:master Aug 21, 2016
@@ -16,5 +16,4 @@ fn test_send<S: Send>() {}

pub fn main() {
test_send::<rand::ThreadRng>();
//~^ ERROR : std::marker::Send` is not satisfied
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't this kind of the point of the test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, thanks for pointing that out -- fixed in #35894.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants