These are temporary.
FunctionInput is conditional on fixing some ranking behavior to not
depend on type variables having argument tuples bound to them.
Hopefully we can replace TVO_PreferSubtypeBinding with a better
mechanism that compares overload types instead.
FunctionResult is used in CSDiag's contextual type diagnostics.
This is also on the chopping block.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
A change was made to attempt to use constraints that we have between
type variables to inform potential bindings, such that if we have:
$T1 <: $T2
we would use $T1's bindings to add to the bindings of $T2. This is
only valid if we're adding bindings where $T1 is the supertype,
though, otherwise we could have the constraints:
$T1 <: $T2
$T1 <: X
imply that $T2 is a supertype of X, which doesn't make sense.
Fixes rdar://problem/40810000 (aka https://bugs.swift.org/browse/SR-7875).
Before checking any requirements of the binding type, let's look
through @autoclosure and/or non-variable types if source constraint
requires that, otherwise we'd end up creating bindings for types
which later on might end up causing infinite recursion like dependent
member types in result position of @autoclosure parameter.
Resolves: rdar://problem/38272904
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
Port multiple test-cases from `test/Constraints/closures.swift`
to SILGen to verify that closures are inferred as having `Void`
result type, and there is no function conversion thunk emitted
to convert from `() -> T` to `() -> Void` for literal closures.
If we could find a binding for type variable representing closure result
let's also add implicit `Void` type as another pontential binding to attempt
because there is an implicit conversion from `() -> T` to `() -> Void`
so finding `Void` early is going to help avoid function conversions down
the line.
Resolves: rdar://problem/37790062
Move all the code specific to dealing with relational constraints out
into a separate function.
I expect to do more refactoring here so this is likely not the final
form for this code - just one step in the direction of breaking things
down into smaller logical pieces.
Attempt to use potential bindings inferred for related types variables
discoverable through 'subtype' constraints, this helps to build a
more precise bindings domain for each type variable.
Resolves: rdar://problem/38159133
Improve support for Optional among other things.
Return Any when it is really the best answer given the types involved,
or nullptr if we cannot yet produce an accurate result.
This implementation returns Any? when joining Any with an
Optional<T>. In our type system both Any and Any? are effectively
subtypes of one another since each can hold all the values that the
other can hold. So this choice is somewhat arbitrary, but does line up
nicely with the notion that T is always a subtype of T?.
Fixes a bug in `getPotentialBindings` when the source of the bindings
is 'OptionalObject' constraint and type variable is on the left-hand
side of that constraint, that makes such type variable always have an
optional type since right-hand side of 'OptionalObject' is its 'object'
type.
Resolves: rdar://problem/37508855
When bindings are picked for particular type variable, right-hand
side of the binding might be another type variable wrapped into optional
type, when trying to determine if both sides of the binding have the
same l-valueness it's imperative to look throught optional type of the
right-hand side. Otherwise new binding might be effectively unsolvable.
Resolves: rdar://problem/37291371
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
If we allow the right-hand type to be bound first, it can artificially
limit the options for the left-hand side, so attempt to delay binding of
the right-hand side types until after we've chosen something for the
left-hand side.
The test here will not fail without this change, but will fail without
this change if the ConstraintGraph.cpp changes from @xedin's edge
contraction patch (https://github.com/apple/swift/pull/11118) are
applied.
When search for potential bindings for the given type variable
encounters `DynamicTypeOf` constraint, its validation should use
representative type variable of the left-hand side instead of
direct comparison.
When trying to find bindings let's avoid type variables which
represent left-hand side of the `DynamicTypeOf` constraint,
because such type variables might be (implicitly) convertible to
[existential] metatype, but at the same time bound to something else
(e.g. Any), which fails when solver tries to simplify `DynamicTypeOf`
constraint itself.
When we saw lvalue- or inout-types we were not appropriately looking at
the underlying types when performing a join. As a result we would infer
Any in cases where we should have inferred a common supertype.
rdar://problem/31127419
Split out the code for selecting potential bindings into a separate file
as a first step before refactoring it for improved clarity and ease of
modification.
