Skip to content

librustc: Properly compare implementation method type parameter bounds #15325

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

Conversation

pcwalton
Copy link
Contributor

@pcwalton pcwalton commented Jul 2, 2014

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

with the corresponding trait parameter bounds.

This is a version of the patch in PR rust-lang#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 rust-lang#2687, as well as the test
case in rust-lang#5886, which is fixed as well by this patch.

Closes rust-lang#2687.
Closes rust-lang#5886.

[breaking-change]
bors added a commit that referenced this pull request Jul 3, 2014
…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
@bors bors closed this Jul 3, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 24, 2023
Normalize expected ty in call arguments

fix rust-lang#15321

I'm not sure if we should do this, or add a normalize in the beginning of `infer_expr_inner`, or somewhere else. r? `@lowr`
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
3 participants