Small constraint solver cleanups #18970
Conversation
We don't get default arguments or varargs here anymore.
There can't actually be GenericFunctionTypes in the constraint system itself.
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
| // FIXME: This should be revisited. If one of argTy or paramTy | ||
| // is a type variable, matchTypes() will add a constraint, and | ||
| // when the constraint is later solved, we will have lost the | ||
| // value of 'subflags'. |
There was a problem hiding this comment.
Yes we really need to fix this at some point...
There was a problem hiding this comment.
It might be best to just try removing this sub flag altogether, instead of recovering it from the locator or whatever.
| @@ -5200,51 +5172,6 @@ Expr *ExprRewriter::coerceTupleToTuple(Expr *expr, TupleType *fromTuple, | |||
| fromElt.getWithType(cs.getType(convertedElt)); | |||
| } | |||
|
|
|||
| // Convert all of the variadic arguments to the destination type. | |||
| ArraySliceType *arrayType = nullptr; | |||
There was a problem hiding this comment.
Just for my own understanding what to double-check - this is dead-code now because parameters in the function type is represented as an array of Param objects and regular tuples can't have variadics, right?
There was a problem hiding this comment.
It was dead even before that. This code path is never taken for function arguments. It is only used when we convert a value of tuple type to another tuple type. Applying the solution to call arguments happens in coerceCallArguments() (which uses Params now, but even before that, it was separate because the rules for call arguments are different from tuple values).
What makes this confusing is that both call arguments and tuple conversions use a TupleShuffleExpr, which supports the union of the transformations needed in both cases. Once all this redundant code is gone it will be easier to split up TupleShuffleExpr into two separate Exprs with very little overlap between them.
There was a problem hiding this comment.
And yes, at the end of all of this, “variadic tuples” and tuples with inouts will no longer be a thing, but it will take us a while to get there. I’ve been mostly focusing on places where we build the old representation; there are more spots where we take it apart, by calling getInput().
A few NFC parts of my work to move the constraint solver over to the new function type representation.