chalk lowering rule: ProjectionEq-Normalize

[csmoe]

cc #49177
r? @scalexm

[scalexm]

I don’t think this will work, what we want to do is to introduce a new type parameter U. Not sure how to do that (probably through tcx.mk_ty_param), I’ll try and get back to you for more guidance.

[csmoe]

thank you.

[scalexm]

Ok so as you can see in the description of the rule, we want the output to be something like:

ProjectionEq(<Self as Trait>::Item = U) :- Normalize(<Self as Trait>::Item = U)

where U is a new type variable. This could be done naively by having:

// add a type param at depth `0`
let ty = tcx.mk_ty_param(0, Symbol::intern(“U”).as_interned_str());

however as you can see, rustc refers to a type param with a depth index and an explicit name (here “U”), instead of referring to all parameters by using indices only. Hence if the name U is already taken, as in:

trait Foo<U> {
    #[rustc_dump_program_clauses]
    type Item;
}

then the output clause will be wrong as it will use the same parameter U for two unrelated things.

A possible fix would be to choose U whenever this name is not already in use, and in case it is used just choose a random name which is not already in use. Another possible fix would be two Binder layers instead of only one, as I think type parameters can have the same name if they are not at the same depth. I’ll confer with niko.

[nikomatsakis]

Hmm so the problem here is that rustc doesn't really support this yet

[nikomatsakis]

I wonder if we can leave this as a kind of FIXME for now

[scalexm]

Ok so as you can see in the description of the rule, we want the output to be something like:

ProjectionEq(<Self as Trait>::Item = U) :- Normalize(<Self as Trait>::Item = U)

where U is a new type variable. This could be done naively by having:

// add a type param at depth `0`
let ty = tcx.mk_ty_param(0, Symbol::intern(“U”).as_interned_str());

however as you can see, rustc refers to a type param with a depth index and an explicit name (here “U”), instead of referring to all parameters by using indices only. Hence if the name U is already taken, as in:

trait Foo<U> {
    #[rustc_dump_program_clauses]
    type Item;
}

then the output clause will be wrong as it will use the same parameter U for two unrelated things.

A possible fix would be to choose U whenever this name is not already in use, and in case it is used just choose a random name which is not already in use. Another possible fix would be two Binder layers instead of only one, as I think type parameters can have the same name if they are not at the same depth. I’ll confer with niko.

[csmoe]

@scalexm thank you, Your instructions will be addressed soon.

[scalexm]

@csmoe I think that’s good now! cc @nikomatsakis, what do you think of the FIXME?

[pietroalbini]

Ping from triage @nikomatsakis! This PR needs your review.

[TimNN]

Ping from triage @nikomatsakis / @rust-lang/compiler: This PR requires your review.

[TimNN]

Ping from triage @rust-lang/compiler / @nikomatsakis: This PR requires your review.

[scalexm]

I propose that we wait for rustc to handle quantification over types, once this is done it should be almost trivial to finish this PR.

[bors]

☔ The latest upstream changes (presumably #54969) made this pull request unmergeable. Please resolve the merge conflicts.

[scalexm]

@bors r+
Unblocked by #55330

[bors]

📌 Commit e853d6c has been approved by scalexm

ok

[bors]

⌛ Testing commit e853d6c with merge 126a0e2...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: scalexm
Pushing 126a0e2 to master...

[rust-highfive]

📣 Toolstate changed by #52153!

Tested on commit 126a0e2.
Direct link to PR: #52153

🎉 rls on windows: test-fail → test-pass (cc @nrc @Xanewok, @rust-lang/infra).