rustc_resolve: allow use crate_name; under uniform_paths.
#54005
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
8 tasks
|
LGTM, awesome! |
|
Setting priority to land for beta ASAP @bors p=100 |
|
This is great 🎉💯❤️ |
|
@bors r+ |
|
📌 Commit 31fce91 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Sep 6, 2018
rustc_resolve: allow `use crate_name;` under `uniform_paths`.
Specifically, `use crate_name;` and `use crate_name::{self, ...};` are now allowed, whereas previously there would produce a (false positive) ambiguity error, as the ambiguity detection code was seeing the `crate_name` import as a locally-available definition to conflict with the crate.
r? @petrochenkov cc @aturon @joshtriplett @Centril
|
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
that referenced
this pull request
Sep 10, 2018
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018. This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests). Also, on top of #54005, this PR allows this as well: ```rust use crate_name; use crate_name::foo; ``` In that any ambiguity between an extern crate and an import *of that same crate* is ignored. r? @petrochenkov cc @aturon @Centril @joshtriplett
bors
added a commit
that referenced
this pull request
Sep 14, 2018
rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's. In particular, this allows this pattern that @cramertj mentioned in #53130 (comment): ```rust use log::{debug, log}; fn main() { use log::{debug, log}; debug!(...); } ``` The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`. Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes). With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice). This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011. Only the last commit is the main change, the other two are cleanups. r? @petrochenkov cc @Centril @joshtriplett
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Specifically,
use crate_name;anduse crate_name::{self, ...};are now allowed, whereas previously there would produce a (false positive) ambiguity error, as the ambiguity detection code was seeing thecrate_nameimport as a locally-available definition to conflict with the crate.r? @petrochenkov cc @aturon @joshtriplett @Centril