Skip to content

Changing order of trait bounds changes available impls #75691

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

Closed
Pratyush opened this issue Aug 19, 2020 · 6 comments
Closed

Changing order of trait bounds changes available impls #75691

Pratyush opened this issue Aug 19, 2020 · 6 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Pratyush
Copy link
Contributor

I tried this code (playground link):

use core::ops::AddAssign;

trait TraitA<B>: Copy + AddAssign<B> + AddAssign<Self> {}

trait TraitC<B> { type Thing: TraitA<B>; }

fn use_c<B, C: TraitC<B>>(mut a: C::Thing, b: B) {
	a += b; // errors
	a += a;
}

I expected this to compile, because the trait bounds on TraitA are sufficient. Instead, rustc fails to find the AddAssign<B> bound for C::Thing, and errors out with the following error message:

  |
7 | fn use_c<B, C: TraitC<B>>(mut a: C::Thing, b: B) {
  |          - this type parameter
8 |     a += b; // errors
  |          ^ expected associated type, found type parameter `B`
  |
  = note: expected associated type `<C as TraitC<B>>::Thing`
              found type parameter `B`
help: consider further restricting this bound
  |
7 | fn use_c<B, C: TraitC<B> + TraitC<B, Thing = B>>(mut a: C::Thing, b: B) {
  |                          ^^^^^^^^^^^^^^^^^^^^^^

(Note that the help message, while technically correct, is actually unhelpful here.)

Meta

This bug occurs in the latest stable, beta, and nightly (this can be verified on the playground link).

This might be related to #41756.

@Pratyush Pratyush added the C-bug Category: This is a bug. label Aug 19, 2020
@Pratyush
Copy link
Contributor Author

Update: this compiles successfully with chalk; the output of

rustc +nightly --crate-name test_chalk --edition=2018 src/lib.rs --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 -C metadata=1ff6265fd5bdefac -C extra-filename=-1ff6265fd5bdefac --out-dir /tmp/test_chalk/target/debug/deps -C incremental=/tmp/test_chalk/target/debug/incremental -L dependency=/tmp/test_chalk/target/debug/deps -C target-cpu=native -Z chalk=yes

is

warning: function is never used: `use_c`
 --> src/lib.rs:7:4
  |
7 | fn use_c<B, C: TraitC<B>>(mut a: C::Thing, b: B) {
  |    ^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

@tesuji

This comment has been minimized.

@rustbot rustbot added A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 17, 2020
@Pratyush
Copy link
Contributor Author

Update: this compiles on the latest nightly. Is there a way to figure out what changed?

@tesuji
Copy link
Contributor

tesuji commented Oct 11, 2020

You could try out bisect-rustc to find which nightly and possibly which PR fix the problem: https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md

@Pratyush
Copy link
Contributor Author

Ahh I think it was this (see “ambiguous projection bounds”) #73905 (comment)

@Pratyush
Copy link
Contributor Author

Can confirm that this is fixed due to #73905; closing.

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) A-trait-system Area: Trait system C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants