Skip to content

Fix ambiguity issue with associated_type_bounds #63393

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

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
# for free to join this conversation on GitHub. Already have an account? # 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