You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Integrate method selection into type inference context properly. For example, s.foo should be resolved to Trait<u32>::method without any ambiguity. (Resolved in Tabled trait resolution #1007)
This could be achieved by maintaining the mapping between a canonical type and a given receiver type in a call site.
Also, the method selector needs to return a TraitInst that relates to the receiver type. In the above example, it will be Canonical<Trait<S, ?0>>. The below one is a more complex case,
In this case, assuming the type of s is S<?10> in the inference context and its canonical form is Canonical<S<?0>>, then the method selector needs to return Canonical<Trait<S<?0>, ?1, ?0>> as a candidate for s.foo. Then, it should be decanonicalized to Trait<S<?10>, ?fresh, ?10> in the inference context, where ?fresh is a new type variable.
Improve error message when function call doesn't satisfy constraints.
Currently, the error message is not so good when function argument/return type doesn't satisfy the constraints.
e.g.,
To address this issue generally, we need to maintain how the generic parameter relates to the argument/return type given by the call site in the type inference phase.
The text was updated successfully, but these errors were encountered:
s.foo
should be resolved toTrait<u32>::method
without any ambiguity. (Resolved in Tabled trait resolution #1007)This could be achieved by maintaining the mapping between a canonical type and a given receiver type in a call site.
Also, the method selector needs to return a
TraitInst
that relates to the receiver type. In the above example, it will beCanonical<Trait<S, ?0>>
. The below one is a more complex case,In this case, assuming the type of
s
isS<?10>
in the inference context and its canonical form isCanonical<S<?0>>
, then the method selector needs to returnCanonical<Trait<S<?0>, ?1, ?0>>
as a candidate fors.foo
. Then, it should be decanonicalized toTrait<S<?10>, ?fresh, ?10>
in the inference context, where?fresh
is a new type variable.Currently, the error message is not so good when function argument/return type doesn't satisfy the constraints.
e.g.,
emits the below error currently.
To address this issue generally, we need to maintain how the generic parameter relates to the argument/return type given by the call site in the type inference phase.
The text was updated successfully, but these errors were encountered: