resolve: fix bug in duplicate checking for extern crates #30295
Conversation
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @nrc |
|
r+ cc @rust-lang/compiler does this need a Crater run? I think not, but does anyone think we should? |
|
@nrc ping? |
|
@bors: r+ |
|
📌 Commit 0310a7a has been approved by |
|
⌛ Testing commit 0310a7a with merge d91bf3f... |
|
💔 Test failed - auto-linux-64-nopt-t |
| @@ -209,6 +211,14 @@ fn resolve_error<'b, 'a: 'b, 'tcx: 'a>(resolver: &'b Resolver<'a, 'tcx>, | |||
| return; | |||
| } | |||
| match resolution_error { | |||
| ResolutionError::NameConflictsWithExternCrate(name) => { | |||
| span_err!(resolver.session, | |||
There was a problem hiding this comment.
This cannot be merged anymore because in master, the type of this match statement has changed. While it still merges cleanly, it will not compile.
There was a problem hiding this comment.
@nagisa Thanks for the diagnosis
jseyfried
force-pushed
the
fix_extern_crate_duplicate
branch
3 times, most recently
from
8ae7d1b to
0c64dda
Compare
jseyfried
force-pushed
the
fix_extern_crate_duplicate
branch
from
0c64dda to
834fb17
Compare
|
@nrc rebased |
|
@bors: r+ |
|
📌 Commit 834fb17 has been approved by |
|
⌛ Testing commit 834fb17 with merge 3917c98... |
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors retry |
Fix a bug allowing an item and an external crate to collide so long as the external crate is declared after the item. For example,
```rust
mod core { pub fn f() {} } // This would be an error if it followed the `extern crate`
extern crate core; // This declaration is shadowed by the preceding module
fn main() { core::f(); }
```
This is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by removing colliding `extern crate` declarations, which are shadowed and hence unused.
|
@bors retry force |
|
@bors r- |
|
@bors r=nrc force |
|
📌 Commit 834fb17 has been approved by |
…e, r=nrc
Fix a bug allowing an item and an external crate to collide so long as the external crate is declared after the item. For example,
```rust
mod core { pub fn f() {} } // This would be an error if it followed the `extern crate`
extern crate core; // This declaration is shadowed by the preceding module
fn main() { core::f(); }
```
This is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by removing colliding `extern crate` declarations, which are shadowed and hence unused.
|
⌛ Testing commit 834fb17 with merge c9b4826... |
|
💔 Test failed - auto-win-gnu-64-nopt-t |
|
@bors: retry On Mon, Jan 11, 2016 at 3:09 PM, bors notifications@github.com wrote:
|
Fix a bug allowing an item and an external crate to collide so long as the external crate is declared after the item. For example,
```rust
mod core { pub fn f() {} } // This would be an error if it followed the `extern crate`
extern crate core; // This declaration is shadowed by the preceding module
fn main() { core::f(); }
```
This is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by removing colliding `extern crate` declarations, which are shadowed and hence unused.
jseyfried
changed the title
Fix a bug allowing an item and an external crate to collide so long as the external crate is declared after the item. For example,
This is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by removing colliding
extern cratedeclarations, which are shadowed and hence unused.