Use `simplifyType` instead with the new parameter
for getting an interface type. Also avoid using
`resolveInterfaceType` in CSApply since we don't
need the opened generic parameter mapping behavior.
Rather than attempting to re-implement `simplifyType`,
tweak `Solution::simplifyType` such that it can
map the resulting type out of context, and can
turn type variables into their opened generic
parameters.
Simplifying into the function expression is wrong,
like `FunctionArgument` this isn't an element that
can be simplified. This also means we don't need
to handle it in `MissingCallFailure`, since we
shouldn't be recording that fix in this case.
This was previously an artificial limitation of the
FunctionRefKind representation, there's no reason
we shouldn't support IUOs for functions referenced
using a compound name.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
Also introduce two new frontend flags:
The -solver-scope-threshold flag sets the maximum number of scopes, which was
previously hardcoded to 1 million.
The -solver-trail-threshold flag sets the maximum number of trail steps,
which defaults to 64 million.
Also, since we add a vertex immediately after introducing a new type
variable, the code path to handle the case where the type variable
had a parent or fixed type was actually dead.
When a protocol which has a read (or modify) requirement is built with
the CoroutineAccessors feature, it gains a read2 (or modify2,
respectively) requirement. For this to be compatible with binaries
built without the feature, a default implementation for these new
requirements must be provided. Cause these new accessor requirements to
have default implementations by returning `true` from
`doesAccessorHaveBody` when the context is a `ProtocolDecl` and the
relevant availability check passes.
When we are using diagnostic transactions to disable immediate emission
of diagnostics, `DiagnosticEngine::hadAnyError()` no longer accurately
reports whether an error occurred. Thread the DiagnosticTransaction
into the ConstraintSystem so we can also check whether it contains an
error before emitting the fallback diagnostic.
Fixes rdar://128272346.
The logic here for completion wasn't actually
helping things since it would result in adding the
var overload to the system, which would result
in an ErrorType binding. We could turn the ErrorType
into a placeholder when resolving the overload,
but the simpler solution is to just allow CSGen
to turn the reference into a PlaceholderType. This
matches what we do for regular solving, and fixes
a crash with an IUO completion.
rdar://89369091
Type checker functions with the prefix "check" usually check some requirement
and then diagnose it if it isn't satisfied. `checkDeclarationAvailability()`
doesn't diagnose on its own, so it should be named differently.
Instead of checking for unavailability attributes directly in the solver, which
does not correctly handle members of unavailable extensions, query
`checkDeclarationAvailability()` instead. By using the same underlying logic as
the availability checker the constraint solver can be confident in the accuracy
of this result.
Resolves rdar://87403752.
My change to preserve type sugar in type transforms introduced a
performance regression here, because openType() is called for
every disjunction choice.
My hope is to optimize the TypeAliasType representation and remove
this at some point, but for now, let's just restore the old
desugaring behavior in this case.
