Skip to content

Implement RFC 1560 behind #![feature(item_like_imports)] #35894

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 18 commits into from
Sep 2, 2016

Conversation

jseyfried
Copy link
Contributor

This implements rust-lang/rfcs#1560 (cc #35120) behind the item_like_imports feature gate.

The RFC text describes the changes to name resolution enabled by #![feature(item_like_imports) in detail. To summarize,

  • Items and named imports shadow glob imports.
  • Multiple globs can import the same name if the name is unused or the imports are shadowed.
  • Multiple globs can import the same name if the imports are of the same item (following re-exports).
    • The visibility of such a name is the maximum visibility of the imports.
    • Equivalently, adding a glob import will never reduce the visibility of a name, nor will removing one increase it.
  • Non-prelude private imports can be used wherever we currently allow private items to be used.
    • Prelude-imported names are unaffected, i.e. they continue to be usable only in lexical scopes.
  • Globs import all visible names, not just public names.
    • Equivalently, glob importing from an ancestor module imports all of the ancestor's names, and glob importing from other modules is unchanged.

r? @nrc

@jseyfried jseyfried force-pushed the new_import_semantics branch 2 times, most recently from 540a351 to a1b7904 Compare August 22, 2016 09:24
@jseyfried
Copy link
Contributor Author

cc @petrochenkov

@bors
Copy link
Collaborator

bors commented Aug 23, 2016

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

@@ -390,7 +388,7 @@ impl<'b> Resolver<'b> {
debug!("(building reduced graph for external crate) building module {} {:?}",
name, vis);
let parent_link = ModuleParentLink(parent, name);
let module = self.new_module(parent_link, Some(def), true);
let module = self.new_module(parent_link, Some(def), DUMMY_NODE_ID);
Copy link
Member

Choose a reason for hiding this comment

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

what does using DUMMY_NODE_ID mean? Seems like it is just ignored when searching, so it would probably be better to use an Option and None here.

Copy link
Contributor Author

@jseyfried jseyfried Aug 24, 2016

Choose a reason for hiding this comment

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

DUMMY_NODE_ID means that the module is from an extern crate, so its nearest normal ancestor doesn't have a node id. normal_ancestor_id is never used on modules from extern crates, so the the choice of node id here isn't particularly relevant.

Copy link
Member

Choose a reason for hiding this comment

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

Then I think it would be better to use Option here, rather than DUMMY_NODE_ID, this seems like the moral equivalent of using null. Put another way, it would be nice to enforce "normal_ancestor_id is never used on modules from extern crates" statically.

Copy link
Contributor Author

@jseyfried jseyfried Aug 28, 2016

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 28, 2016

r=me with the last comments addressed.

@bors
Copy link
Collaborator

bors commented Aug 28, 2016

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

@jseyfried jseyfried force-pushed the new_import_semantics branch from 6a88bc1 to 58616c8 Compare August 29, 2016 06:08
@jseyfried
Copy link
Contributor Author

@bors r=nrc

@bors
Copy link
Collaborator

bors commented Aug 29, 2016

📌 Commit 58616c8 has been approved by nrc

@bors
Copy link
Collaborator

bors commented Aug 29, 2016

⌛ Testing commit 58616c8 with merge 614a792...

@bors
Copy link
Collaborator

bors commented Aug 29, 2016

💔 Test failed - auto-win-gnu-32-opt-rustbuild

@jseyfried
Copy link
Contributor Author

@bors retry

@bors
Copy link
Collaborator

bors commented Aug 29, 2016

⌛ Testing commit 58616c8 with merge 7f96d62...

@bors
Copy link
Collaborator

bors commented Aug 29, 2016

💔 Test failed - auto-mac-64-opt-rustbuild

@arielb1
Copy link
Contributor

arielb1 commented Aug 29, 2016

@bors retry

@jseyfried jseyfried force-pushed the new_import_semantics branch from 7155c77 to bba8b09 Compare September 1, 2016 22:31
@jseyfried
Copy link
Contributor Author

@bors r=nrc

@bors
Copy link
Collaborator

bors commented Sep 1, 2016

📌 Commit bba8b09 has been approved by nrc

@jseyfried jseyfried force-pushed the new_import_semantics branch from bba8b09 to 90ce504 Compare September 2, 2016 00:35
@jseyfried
Copy link
Contributor Author

@bors r=nrc

@bors
Copy link
Collaborator

bors commented Sep 2, 2016

📌 Commit 90ce504 has been approved by nrc

@bors
Copy link
Collaborator

bors commented Sep 2, 2016

⌛ Testing commit 90ce504 with merge 8aeb15a...

bors added a commit that referenced this pull request Sep 2, 2016
Implement RFC 1560 behind `#![feature(item_like_imports)]`

This implements rust-lang/rfcs#1560 (cc #35120) behind the `item_like_imports` feature gate.

The [RFC text](https://github.com/rust-lang/rfcs/blob/master/text/1560-name-resolution.md#changes-to-name-resolution-rules) describes the changes to name resolution enabled by `#![feature(item_like_imports)` in detail. To summarize,
 - Items and named imports shadow glob imports.
 - Multiple globs can import the same name if the name is unused or the imports are shadowed.
 - Multiple globs can import the same name if the imports are of the same item (following re-exports).
  - The visibility of such a name is the maximum visibility of the imports.
  - Equivalently, adding a glob import will never reduce the visibility of a name, nor will removing one increase it.
 - Non-prelude private imports can be used wherever we currently allow private items to be used.
  - Prelude-imported names are unaffected, i.e. they continue to be usable only in lexical scopes.
 - Globs import all visible names, not just public names.
  - Equivalently, glob importing from an ancestor module imports all of the ancestor's names, and glob importing from other modules is unchanged.

r? @nrc
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants