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

Forbid items with the same name from appearing in overlapping inherent impl blocks #31925

Merged
merged 5 commits into from
Mar 12, 2016

Conversation

aturon
Copy link
Member

@aturon aturon commented Feb 26, 2016

For example, the following is now correctly illegal:

struct Foo;

impl Foo {
    fn id() {}
}

impl Foo {
    fn id() {}
}

"Overlapping" here is determined the same way it is for traits (and in fact shares the same code path): roughly, there must be some way of substituting any generic types to unify the impls, such that none of the where clauses are provably unsatisfiable under such a unification.

Along the way, this PR also introduces an ImplHeader abstraction (the first commit) that makes it easier to work with impls abstractly (without caring whether they are trait or inherent impl blocks); see the first commit.

Closes #22889
r? @nikomatsakis

@brson brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Feb 29, 2016
@bors
Copy link
Contributor

bors commented Mar 3, 2016

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

@nikomatsakis
Copy link
Contributor

r=me once rebased, I think. I just had a few nits, nothing important. Address or don't. :)

@aturon aturon force-pushed the inherent-overlap branch from f031e4e to 4804ef9 Compare March 8, 2016 20:31
@aturon
Copy link
Member Author

aturon commented Mar 8, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 8, 2016

📌 Commit 4804ef9 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 9, 2016

⌛ Testing commit 4804ef9 with merge 2ca41f0...

@bors
Copy link
Contributor

bors commented Mar 9, 2016

💔 Test failed - auto-linux-64-opt

@aturon aturon force-pushed the inherent-overlap branch from 4804ef9 to 46485f0 Compare March 9, 2016 16:52
@aturon
Copy link
Member Author

aturon commented Mar 9, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 9, 2016

📌 Commit 0038777 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 10, 2016

🔒 Merge conflict

@bors
Copy link
Contributor

bors commented Mar 10, 2016

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

@aturon aturon force-pushed the inherent-overlap branch from 0038777 to e3a74b9 Compare March 11, 2016 15:08
@aturon
Copy link
Member Author

aturon commented Mar 11, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 11, 2016

📌 Commit e3a74b9 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 11, 2016

⌛ Testing commit e3a74b9 with merge a5f6b36...

@bors
Copy link
Contributor

bors commented Mar 11, 2016

💔 Test failed - auto-mac-64-nopt-t

This commit introduces the idea of an "impl header", which consists of
everything outside the impl body: the Self type, the trait
reference (when applicable), and predicates from `where` clauses. This
type is usable with the type folding machinery, making it possible to
work with impl headers at a higher and more generic level.
@aturon aturon force-pushed the inherent-overlap branch from e3a74b9 to 66bdfe5 Compare March 11, 2016 18:36
@aturon
Copy link
Member Author

aturon commented Mar 11, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 11, 2016

📌 Commit 66bdfe5 has been approved by nikomatsakis

aturon added 3 commits March 11, 2016 10:59
impl blocks.

For example, the following is now correctly illegal:

```rust
struct Foo;

impl Foo {
    fn id() {}
}

impl Foo {
    fn id() {}
}
```

"Overlapping" here is determined the same way it is for traits (and in
fact shares the same code path): roughly, there must be some way of
substituting any generic types to unify the impls, such that none of the
`where` clauses are provably unsatisfiable under such a unification.

Closes rust-lang#22889
…at a regression test already exists for *non*overlapping impls.
@aturon aturon force-pushed the inherent-overlap branch from 66bdfe5 to 2234b55 Compare March 11, 2016 18:59
@aturon
Copy link
Member Author

aturon commented Mar 11, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 11, 2016

📌 Commit 2234b55 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 11, 2016

⌛ Testing commit 2234b55 with merge 62d4b8d...

@bors
Copy link
Contributor

bors commented Mar 11, 2016

💔 Test failed - auto-mac-64-nopt-t

@aturon
Copy link
Member Author

aturon commented Mar 12, 2016

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 12, 2016

📌 Commit 6265b6b has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 12, 2016

⌛ Testing commit 6265b6b with merge 1a019dc...

bors added a commit that referenced this pull request Mar 12, 2016
Forbid items with the same name from appearing in overlapping inherent impl blocks

For example, the following is now correctly illegal:

```rust
struct Foo;

impl Foo {
    fn id() {}
}

impl Foo {
    fn id() {}
}
```

"Overlapping" here is determined the same way it is for traits (and in fact shares the same code path): roughly, there must be some way of substituting any generic types to unify the impls, such that none of the `where` clauses are provably unsatisfiable under such a unification.

Along the way, this PR also introduces an `ImplHeader` abstraction (the first commit) that makes it easier to work with impls abstractly (without caring whether they are trait or inherent impl blocks); see the first commit.

Closes #22889
r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants