-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Small constraint solver cleanups #18970
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -883,6 +883,10 @@ matchCallArguments(ConstraintSystem &cs, ConstraintKind kind, | |
paramIdx)); | ||
auto argTy = args[argIdx].getType(); | ||
|
||
// 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes we really need to fix this at some point... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might be best to just try removing this sub flag altogether, instead of recovering it from the locator or whatever. |
||
if (!haveOneNonUserConversion) { | ||
subflags |= ConstraintSystem::TMF_ApplyingOperatorParameter; | ||
} | ||
|
@@ -1403,7 +1407,7 @@ ConstraintSystem::matchExistentialTypes(Type type1, Type type2, | |
|
||
// Conformance to 'Any' always holds. | ||
if (type2->isAny()) { | ||
auto *fnTy = type1->getAs<AnyFunctionType>(); | ||
auto *fnTy = type1->getAs<FunctionType>(); | ||
if (!fnTy || !fnTy->isNoEscape()) | ||
return getTypeMatchSuccess(); | ||
|
||
|
@@ -1602,7 +1606,7 @@ ConstraintSystem::matchTypesBindTypeVar( | |
// Disallow bindings of noescape functions to type variables that | ||
// represent an opened archetype. If we allowed this it would allow | ||
// the noescape function to potentially escape. | ||
if (auto *fnTy = type->getAs<AnyFunctionType>()) { | ||
if (auto *fnTy = type->getAs<FunctionType>()) { | ||
if (fnTy->isNoEscape() && typeVar->getImpl().getArchetype()) { | ||
if (shouldAttemptFixes()) { | ||
auto *fix = MarkExplicitlyEscaping::create( | ||
|
@@ -2136,7 +2140,7 @@ ConstraintSystem::matchTypes(Type type1, Type type2, ConstraintKind kind, | |
// Penalize conversions to Any, and disallow conversions of | ||
// noescape functions to Any. | ||
if (kind >= ConstraintKind::Conversion && type2->isAny()) { | ||
if (auto *fnTy = type1->getAs<AnyFunctionType>()) { | ||
if (auto *fnTy = type1->getAs<FunctionType>()) { | ||
if (fnTy->isNoEscape()) { | ||
if (shouldAttemptFixes()) { | ||
auto &ctx = getASTContext(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thank you!