These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
Checking type variables is no longer necessary because constraint
system now stores types of all closures it encountered, this makes
detection logic more reliable as well.
Resolves: rdar://112426330
The fix used incorrect locators for attempted argument conversions,
didn't check whether arguments are already re-ordered and allowed
fixes as visible side-effects from checking.
Resolves: rdar://114341979
A type variable that represents a key path literal cannot be bound
directly to `AnyKeyPath` or `PartialKeyPath`, such types could only
be used for conversions.
It used to be the task of the binding inference to infer `AnyKeyPath`
and `PartiaKeyPath` as a `KeyPath` using previously generated type
variables for a root and value associated with key path literal
(previously stored in the locator).
Recently we switched over to storing key path information in the
constraint system and introduced `resolveKeyPath` method to gain
more control over how key path type variable gets assigned.
Getting information from the constraint system creates a problem
for the inference because "undo" for some bindings would be run
after solver scope has been erased, so instead of modifying bindings
in `inferFromRelational`, let's do that in `resolveKeyPath` right
before the key path type variable gets bound which seems to be a
better place for that logic anyway.
Resolves: rdar://113760727
If type variable we are about to bind represents a pack
expansion type, allow the binding to happen regardless of
what the \c type is, because contextual type is just a hint
in this situation and type variable would be bound to its
opened type instead.
Resolves: rdar://112617922
If either source or destination type is a hole conversion should
just be ignored because there is no r-value or other mismatch that
could be diagnosed in this case.
Placeholder types just like type variables are set up to return
a conformance ref which, in this case, would mean that we'd produce
an invalid diagnostic.
Such tuples should be treated specially because once pack expansion
is sufficiently resolved they'd get exploded and the resulting type
is what member lookup should use as a base.
Resolves: rdar://110721928
`same-shape` mismatch detection logic shouldn't expect that types are
always packs because they could be either invalid (i.e. Void) or pack
archetypes too.
Resolves: rdar://112090069
by creating a BoundGenericType for the keypath expr
with the keypath base and replacing the value with
the value typeVar that will be resolved when the value
typeVar is directly bound.
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Generate a conjunction for each tap expression body as soon as it
gets a contextual type instead of separate post-factum type-checking
via `typeCheckTapBody`.
As described in the issue #62922, the compiler should not allow to discard @noDerivative attribute and keep @differentiable. The patch adds a diagnostic for this case.
Resolves#62922.
