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.

Sign up for GitHub

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

Jump to bottom

nested bounds on traits aren't properly checked #5886

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-traits Area: Trait system A-typesystem Area: The 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-traits Area: Trait system A-typesystem Area: The 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