Rust: Implement type inference for trait objects/dyn types
#20084
Conversation
59e3ac7 to
8de4313
Compare
55c3674 to
219e26e
Compare
|
Note: The first DCA run showed an increase in type inference inconsistencies. I've fixed those and started a second DCA run. EDIT: The second DCA shows that the type inference inconsistencies are now fixed. The number of type inference inconsistencies now only decreases. |
e301fd5 to
f5605c9
Compare
| override TupleField getTupleField(int i) { none() } | ||
|
|
||
| override DynTraitTypeParameter getTypeParameter(int i) { | ||
| result = TDynTraitTypeParameter(trait.getGenericParamList().getTypeParam(i)) |
There was a problem hiding this comment.
How come the definition of TDynTraitTypeParameter (on line 34) uses .getAGenericParam(), but here we use .getTypeParam(i)? I was expecting them to match.
There was a problem hiding this comment.
Good point. I've changed the getAGenericParam to getATypeParam 👍. I didn't think much of the difference, but I guess the former can contain stuff that are not type parameters (lifetimes?) so using getATypeParam is probably more correct.
| @@ -97,6 +97,9 @@ private module Input1 implements InputSig1<Location> { | |||
| id = 2 | |||
| or | |||
| kind = 1 and | |||
| id = idOfTypeParameterAstNode(tp0.(DynTraitTypeParameter).getTypeParam()) | |||
There was a problem hiding this comment.
Why is this separate from the cases for kind = 2? Can a DynTraitTypeParameter overlap with one or more of the cases in the bit below?
There was a problem hiding this comment.
Yes, TypeParamTypeParameter below uses the same TypeParam AST nodes so we need a new kind.`
This PR implements support for trait objects on the form
dyn Trait.The implementation works as follows:
dyn Traitappears somewhere as a declared type then we create aDynTraitTypethat consists of the traitTrait.dyn Traithas a type parameter for every type parameter ofTrait. There is a 1-to-1 correspondence but they're not equal.dyn Traittype is made to implementTraitas if there was animpl<A, B, ...> Trait<A, B, ...> for dyn Trait<A, B, ..>block in the source.Currently the PR doesn't account for the auto traits that one can specify with a
+, for instancedyn Clone + Send + Sync. I don't know if we have a need to consider those, but if we do it should be possible by building on top of the work in this PR.DCA shows a 0.33% point increase in resolved call targets and no change in analysis time.