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

Fix ambiguity issue with associated_type_bounds #63393

Closed
iluuu1994 opened this issue Aug 8, 2019 · 4 comments · Fixed by #63584
Closed

Fix ambiguity issue with associated_type_bounds #63393

iluuu1994 opened this issue Aug 8, 2019 · 4 comments · Fixed by #63584
Assignees
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example F-associated_type_bounds `#![feature(associated_type_bounds)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@iluuu1994
Copy link
Contributor

Follow up of #61738.

These two particular cases could not be refactored due to an ambiguity issue:


impl<I: DoubleEndedIterator, U, F> DoubleEndedIterator for FlatMap<I, U, F>
where F: FnMut(I::Item) -> U,
U: IntoIterator,
U::IntoIter: DoubleEndedIterator
{
#[inline]
fn next_back(&mut self) -> Option<U::Item> { self.inner.next_back() }

With #![feature(associated_type_bounds)]

impl<I: DoubleEndedIterator, U, F> DoubleEndedIterator for FlatMap<I, U, F>
where
    F: FnMut(I::Item) -> U,
    U: IntoIterator<IntoIter: DoubleEndedIterator>,
{
    #[inline]
    fn next_back(&mut self) -> Option<U::Item> { self.inner.next_back() }

Result (line numbers are off):

error[E0221]: ambiguous associated type `Item` in bounds of `U`
   --> src/libcore/iter/adapters/flatten.rs:77:39
    |
77  |     fn next_back(&mut self) -> Option<U::Item> { self.inner.next_back() }
    |                                       ^^^^^^^ ambiguous associated type `Item`
    |
   ::: src/libcore/iter/traits/iterator.rs:94:5
    |
94  |     type Item;
    |     ---------- ambiguous `Item` from `iter::traits::iterator::Iterator`
    |
   ::: src/libcore/iter/traits/collect.rs:211:5
    |
211 |     type Item;
    |     ---------- ambiguous `Item` from `iter::traits::collect::IntoIterator`

pub struct Flatten<I: Iterator>
where I::Item: IntoIterator {
inner: FlattenCompat<I, <I::Item as IntoIterator>::IntoIter>,
}

With #![feature(associated_type_bounds)]

pub struct Flatten<I: Iterator<Item: IntoIterator>> {
    inner: FlattenCompat<I, <I::Item as IntoIterator>::IntoIter>,
}

Result (line numbers are off):

error[E0221]: ambiguous associated type `Item` in bounds of `I`
   --> src/libcore/iter/adapters/flatten.rs:112:30
    |
112 |     inner: FlattenCompat<I, <I::Item as IntoIterator>::IntoIter>,
    |                              ^^^^^^^ ambiguous associated type `Item`
    |
   ::: src/libcore/iter/traits/collect.rs:211:5
    |
211 |     type Item;
    |     ---------- ambiguous `Item` from `iter::traits::collect::IntoIterator`
    |
   ::: src/libcore/iter/traits/iterator.rs:94:5
    |
94  |     type Item;
    |     ---------- ambiguous `Item` from `iter::traits::iterator::Iterator`

cc @Centril @alexreg

@estebank estebank added A-associated-items Area: Associated items (types, constants & functions) F-associated_type_bounds `#![feature(associated_type_bounds)]` T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 8, 2019
@Centril Centril added C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. requires-nightly This issue requires a nightly compiler in some way. and removed T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 8, 2019
@Centril
Copy link
Contributor

Centril commented Aug 8, 2019

cc also @nikomatsakis

@Centril Centril added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Aug 8, 2019
@alexreg
Copy link
Contributor

alexreg commented Aug 9, 2019

Thanks for this report. If you/Centril/someone could produce a MCVE, I would then be happy to investigate further... right now I don't have the time to reduce it though, I'm afraid.

@iluuu1994
Copy link
Contributor Author

I tried again for an hour or two without success. Unfortunately I don't know enough about the internals to understand how this could happen. I'll look at the associated type bounds PR, maybe that will help.

@Centril
Copy link
Contributor

Centril commented Aug 14, 2019

This is odd; I basically pasted the code in flatten.rs verbatim into the playground, made it compile, and the made the tweaks above. The issue still won't reproduce but it does reproduce when I ./x.py check.

Maybe this is a bootstrapping issue... in which case we'll know in a few hours.

Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 15, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Centril added a commit to Centril/rust that referenced this issue Aug 16, 2019
… r=alexreg

libcore: more cleanups using `#![feature(associated_type_bounds)]`

Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after rust-lang#63534 merged.

Closes rust-lang#63393

r? @alexreg
cc @iluuu1994
cc rust-lang#52662
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example F-associated_type_bounds `#![feature(associated_type_bounds)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants