Make sure that presence of `@autoclosure` attribute handled
in one place - `matchCallArguments`, which makes it possible
to remove the rest of (now redundant) autoclosure related
logic scattered throughout solver.
When `bind param` constraint is associated with a given
type variable a set of bindings collected for it is
potentially incomplete, because binding gathering doesn't
look through related type variables. Which means that
such type variable has to be de-prioritized until
`bind param` constraint is resolved or there is just
nothing else to try, otherwise there is a risk that
solver would skip some of the valid solutions.
This only affects type variable that appears one the
right-hand side of the `bind param` constraint and
represents result type of the closure body, because
left-hand side gets types from overload choices.
Resolves: rdar://problem/45659733
* Implement dynamically callable types (`@dynamicCallable`).
- Implement dynamically callable types as proposed in SE-0216.
- Dynamic calls are resolved based on call-site syntax.
- Use the `withArguments:` method if it's defined and there are no
keyword arguments.
- Otherwise, use the `withKeywordArguments:` method.
- Support multiple `dynamicallyCall` methods.
- This enables two scenarios:
- Overloaded `dynamicallyCall` methods on a single
`@dynamicCallable` type.
- Multiple `dynamicallyCall` methods from a `@dynamicCallable`
superclass or from `@dynamicCallable` protocols.
- Add `DynamicCallableApplicableFunction` constraint. This, used with
an overload set, is necessary to support multiple `dynamicallyCall`
methods.
When `bind param` constraint is associated with a given type
variable a set of bindings collected for it is potentially
incomplete, because binding gathering doesn't look through related
type variables. Which means that such type variable has to be
de-prioritized until `bind param` constraint is resolved
or there is just nothing else to try, otherwise there is a
risk that solver would skip some of the valid solutions.
Resolves: rdar://problem/45659733
Improve enumerateDirectSupertypes so that for T? it will return U? if
U is a supertype of T. This is another form of direct supertype.
This is making up for a deficiency in the completeness of our Type
join implementation, which should be able to directly compute a join
of disparate types that share some common supertype, but sometimes
fails to in cases involving protocol compositions.
Fixes rdar://problem/45490737
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
`DisjunctionStep` attempts all of the viable choices,
at least one of the choices has to succeed for disjunction
to be considered a success.
`DisjunctionStep` attempts each choice and generates followup
`SplitterStep` to see if applying choice to constraint system
resulted in any simplification.
Introduce `TypeBinding` interface with a single `attempt` method
which is useful to encapsulate specific binding logic used for
attempting disjunction choices and type variable bindings under
a single interface. This makes it easier to unify top-level logic
responsible for binding enumeration.
It should also make it possible to introduce unified binding producer
interface in the future.
Encapsulate most of the logic related to new binding generation
and iteration into `TypeVarBindingGenerator`. `tryTypeVariableBindings`
is only responsible for attempting bindings and recording results.
One more step towards iterative solver.
* Move logic to ensure that r-value type var would get r-value type to `PotentialBindings`;
* Strip uncessary parens directly when creating `PotentialBinding`;
* Check if the binding is viable before inclusion in the set, instead of filtering it later;
* Assert that bindings don't have types with errors included in the set.
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.
