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
This effectively reverts 6823744779
The blanket removal of isolation in default-value expressions had
unintented consequences for important workflows. It's still
a problem that needs to be addressed, but we need to be more precise
about the problematic situations.
Fixes a crash during diagnostics by not assuming that optional chain
would always produce an optional type, which is not true because in
error scenarios it could get assigned an invalid type from context.
Resolves: rdar://85516390
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
`one-way` constraints disable some optimizations related to component
selection because they imply strict ordering. This is a problem for
multi-statement closures because variable declarations could involve
complex operator expressions that rely on aforementioned optimizations.
In order to fix that, let's move away from solving whole pattern binding
declaration into scheme that explodes such declarations into indvidual
elements and inlines them into a conjunction.
For example:
```
let x = 42, y = x + 1, z = (x, test())
```
Would result in a conjunction of three elements:
```
x = 42
y = x + 1
z = (x, test())
```
Each element is solved indepedently, which eliminates the need for
`one-way` constraints and re-enables component selection optimizations.
`repairFailures` needs a special case when l-value conversion is
associated with a result type of subscript setter because otherwise
it falls through and treats result type as if it's an argument type,
which leads to crashes.
Resolves: rdar://84580119
