Skip to content

nested bounds on traits aren't properly checked #5886

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

Jump to bottom
Closed
thestinger opened this issue Apr 15, 2013 · 5 comments
Closed

nested bounds on traits aren't properly checked #5886

thestinger opened this issue Apr 15, 2013 · 5 comments
Labels
A-trait-system Area: Trait system A-type-system Area: Type system
Milestone
1.0

Comments

@thestinger
Copy link
Contributor

U: Iterator<U> is used in the trait and U: Iterator<B> in the impl

trait Iterator<A> {
    fn next(&mut self) -> Option<A>;
}

trait IteratorUtil<A> {
    fn zip<B, U: Iterator<U>>(self, other: U) -> ZipIterator<Self, U>;
}

impl<A, T: Iterator<A>> IteratorUtil<A> for T {
    fn zip<B, U: Iterator<B>>(self, other: U) -> ZipIterator<T, U> {
        ZipIterator{a: self, b: other}
    }
}

struct ZipIterator<T, U> {
    a: T, b: U
}
@bblum
Copy link
Contributor

bblum commented Jul 13, 2013

Wow, that seems pretty bad. Nominating well-covered milestone.

@pnkfelix
Copy link
Member

accepted for production ready

@pnkfelix
Copy link
Member

Accepted as 1.0 blocker. Assigning P-backcompat-lang.

@nikomatsakis
Copy link
Contributor

cc me, cc #5527

@pnkfelix pnkfelix added this to the 1.0 milestone Feb 13, 2014
@pcwalton
Copy link
Contributor

pcwalton commented Jul 2, 2014

Fixed by my WIP patch for #2687.

@pcwalton pcwalton mentioned this issue Jul 2, 2014
Closed
bors added a commit that referenced this issue Jul 3, 2014
@bors
auto merge of #15325 : pcwalton/rust/trait-impl-bound-mismatch, r=pnk…
67776ba 
…felix

with the corresponding trait parameter bounds.

This is a version of the patch in PR #12611 by Florian Hahn, modified to
address Niko's feedback.

It does not address the issue of duplicate type parameter bounds, nor
does it address the issue of implementation-defined methods that contain
*fewer* bounds than the trait, because Niko's review indicates that this
should not be necessary (and indeed I believe it is not). A test has
been added to ensure that this works.

This will break code like:

    trait Foo {
        fn bar<T:Baz>();
    }

    impl Foo for Boo {
        fn bar<T:Baz + Quux>() { ... }
        //             ^~~~ ERROR
    }

This will be rejected because the implementation requires *more* bounds
than the trait. It can be fixed by either adding the missing bound to
the trait:

    trait Foo {
        fn bar<T:Baz + Quux>();
        //             ^~~~
    }

    impl Foo for Boo {
        fn bar<T:Baz + Quux>() { ... }  // OK
    }

Or by removing the bound from the impl:

    trait Foo {
        fn bar<T:Baz>();
    }

    impl Foo for Boo {
        fn bar<T:Baz>() { ... }  // OK
        //       ^ remove Quux
    }

This patch imports the relevant tests from #2687, as well as the test
case in #5886, which is fixed as well by this patch.

Closes #2687.
Closes #5886.

[breaking-change]

r? @pnkfelix
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 11, 2020
@bors
Auto merge of rust-lang#5889 - ebroto:5886_or_fun_call_const_0_args, …
1683189 
…r=Manishearth

Avoid or_fun_call for const_fn with no args

Based on rust-lang#5682 by @lzutao

This avoids a subset of false positives, specifically those related to `const fn`s that take no arguments.
For the rest, a much more involved fix would be needed, see rust-lang/rust-clippy#5682 (comment).

So this does *not* solve rust-lang#5658

changelog: Avoid triggering [`or_fun_call`] with `const fn`s that take no arguments.

Fixes rust-lang#5886
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
A-trait-system Area: Trait system A-type-system Area: Type system
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

librustc: Properly compare implementation method type parameter bounds pcwalton/rust
5 participants
@nikomatsakis @pcwalton @pnkfelix @thestinger @bblum