Skip to content

resolve: Simplify treatment of ambiguity errors #57199

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 1 commit into from
Jan 1, 2019

Conversation

petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Dec 29, 2018

If we have a glob conflict like this

mod m1 { struct S; }
mod m2 { struct S; }

use m1::*;
use m2::*;

we treat it as a special "ambiguity item" that's not an error by itself, but produces an error when actually used.

use m1::*; // primary
use m2::*; // secondary

=>

ambiguity S(m1::S, m2::S);

Ambiguity items were sometimes treated as their primary items for error recovery, but pretty irregularly.

After this PR they are always treated as their primary items, except that

  • If an ambiguity item is marked as used, then it still produces an error.
  • Ambiguity items are still filtered away when exported to other crates (which is also a use in some sense).

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 29, 2018
@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Dec 31, 2018

📌 Commit 06f22ba has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 31, 2018
@bors
Copy link
Collaborator

bors commented Jan 1, 2019

⌛ Testing commit 06f22ba with merge d8371c6...

bors added a commit that referenced this pull request Jan 1, 2019
resolve: Simplify treatment of ambiguity errors

If we have a glob conflict like this
```rust
mod m1 { struct S; }
mod m2 { struct S; }

use m1::*;
use m2::*;
```
we treat it as a special "ambiguity item" that's not an error by itself, but produces an error when actually used.
```rust
use m1::*; // primary
use m2::*; // secondary

=>

ambiguity S(m1::S, m2::S);
```

Ambiguity items were *sometimes* treated as their primary items for error recovery, but pretty irregularly.

After this PR they are always treated as their primary items, except that
- If an ambiguity item is marked as used, then it still produces an error.
- Ambiguity items are still filtered away when exported to other crates (which is also a use in some sense).
@bors
Copy link
Collaborator

bors commented Jan 1, 2019

☀️ Test successful - status-appveyor, status-travis
Approved by: estebank
Pushing d8371c6 to master...

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants