Inject `buildBlock` call into `return`, `buildFinalResult`, and
`build{Optional, Either}` to take advantage of contextual information
and maintain compatibility with current inference behavior.
Invalid syntax could introduce type variables into sequence which
have to be brought into scope otherwise solver is going to crash.
Resolves: rdar://100753270
If a (partial) solution has a type variable it could only be unbound
if `FreeTypeVariableBinding` is set to `Allow`, in all other cases
solution would either have a fully resolved type or a hole.
`applySolution` shouldn't second guess `finalize()` and just apply
a solution as given. This is very important for multi-statement closures
because their elements are solved in isolation and opaque value types
inferred for their result could contain not-yet-resolved type variables
from outer context in their substitution maps (which it totally legal
under bi-directional inference).
Update `applyPropertyWrapperToParameter` to set types to projected
and wrapped values and allow `TypeVariableRefFinder` to skip decls
with implicit property wrappers that are not yet resolved.
Reference to `makeIterator` in for-in loop context needs to be
treated as a reference to a witness of `Sequence#makeIterator`
requirement, otherwise it could lead to problems with retroactive
conformances.
Using `computeWrappedValueType` is incorrect because
that return a type of the wrapped variable and not
the *wrapper* variable (one that starts with `_`).
Resolves: https://github.com/apple/swift/issues/61017
If the failure is not reflected in constraint system it would let
the solver to form a _valid_ solution as if the constraint between
the type variable and the unresolved dependent member type never
existed.
Resolves: https://github.com/apple/swift/issues/60649
`ExprRewriter::coerceToType` should canonicalize contextual type before
attempting to use it for value abstraction, because sugared type could
have typealias references that hide their underlying opaque result types.
Resolves: rdar://98577451
To support referencing projected and/or wrapped var
in a closure solver needs to lookup a type of their
originator and based on the wrapper type compute and
assign types to projection and/or wrapper.
Resolves: https://github.com/apple/swift/issues/59295
Resolves: rdar://94506352
To make this test work, fix an issue in `ConstraintSystem::salvage` where a
threshold breach during solving went unnoticed due to exiting on ambiguity
before reaching the `isTooComplex` check. Address this by moving the
`isTooComplex` check to before we start processing solutions, and stick another
one in `findBestSolution` for short-circuiting while we're here.
Property wrappers trigger initializer synthesis. Synthesized
initializers should not be re-typechecked when encountered e.g.
while re-solving closure with a different contextual type.
Resolves: https://github.com/apple/swift/issues/59294
Resolves: rdar://94506352
`RelabelArguments` cannot possibly diagnose this issue because there
are no argument lists in this case. Let's report contextual mismatch
instead.
Resolves: https://github.com/apple/swift/issues/59058
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
`EnumElement` patterns with optional base type do member lookup
on both optional type and its wrapped type but do not synthesize
`~=` operator call.
Resolves: rdar://92327807
Multi-statement closure + simd perf test-case still (albeit very
rarely) fails, so let's remove `/ 4` in attempt to prevent that
happening.
Resolves: rdar://92025732
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
When construction call is rewritten into a tuple conversion,
rewriter has to make sure that AST types are reset otherwise
it would end up with types set by `packIntoImplicitTupleOrParen`
which could contain l-values.
Resolves: rdar://90366182
This is a follow-up to https://github.com/apple/swift/pull/40708 which only considers
closures, but it missed the case when builder is applied to function body - in such
cases the declaration context is going to be a function/getter declaration.
Resolves: rdar://91150414
`typeEraseExistentialSelfReferences` shouldn't account for
contextual signature because that signature could have
generic parameters of it's own unrelated to the reference
which would be located before generic parameters of the
member, e.g. when the code is located in a protocol extension,
which invalidates the assumption that `Self` is located at
depth = 0, index = 0.
Resolves: rdar://91110069
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
