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.
Instead of starting a depth-first search from each type variable
and marking all type variables that haven't been marked yet,
we can implement this as a union-find.
We can also store the temporary state directly inside the
TypeVariableType::Implementation, instead of creating large
DenseMaps whose keys range over all type variables.
Don't attempt this optimization if call has number literals.
This is intended to narrowly fix situations like:
```swift
func test<T: FloatingPoint>(_: T) { ... }
func test<T: Numeric>(_: T) { ... }
test(42)
```
The call should use `<T: Numeric>` overload even though the
`<T: FloatingPoint>` is a more specialized version because
selecting `<T: Numeric>` doesn't introduce non-default literal
types.
Helps situations like `1 + {Double, CGFloat}(...)` by inferring
a type for the second operand of `+` based on a type being constructed.
Currently limited to Double and CGFloat only since we need to
support implicit `Double<->CGFloat` conversion.
Helps situations like `1 + CGFloat(...)` by inferring a type for
the second operand of `+` based on a type being constructed.
Currently limited to known integer, floating-point and CGFloat types
since we know how they are structured.
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.
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.
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.
