This is already accounted for by `determineBestChoicesInContext`
and reflected in the overall score, which means that we no longer
need to use this in vacuum.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
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.
Currently we set `FunctionRefKind::Compound` for
enum element patterns with tuple sub-patterns to
ensure the member has argument labels stripped. As
such, we need to account for the correct application
level in `getNumApplications`. We ought to be
setting the correct FunctionRefKind and properly
handling the label matching in the solver though.
We also ought to consider changing FunctionRefKind
such that "is compound" is a separate bit from the
application level.
rdar://139234188
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.
PotentialBindings is part of ConstraintGraphNode and there's no need
to store the ConstraintSystem and TypeVariableType twice.
Also it doesn't need to be optional either, because we no longer need
to reset and recompute bindings.
All but two remaining call sites can be changed to just check for a
non-null solverState, because we want to assert if we're inside
of an active undo.
The two places inside binding inference can check isUndoActive()
directly.
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.
Local functions can capture variables from parent
closures, so we need to make sure we type-check
parent closures when doing completion in a local
function. Ideally we ought to be able to be more
selective about the elements of the parent closure
that we type-check, but that's a more complex change
I'm leaving as future work for now.
Until `ApplicableFunction` constraint is simplified result type
associated with it cannot be bound because the binding set if
incomplete.
Resolves: rdar://139237088
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.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
