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.
