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.
Previously, the AbstractionPattern that was used for the value
"returned" (i.e. via a completion handler) from ObjC mostly (but not
quite always) was "type".
The generated completion handler correctly (because this is required in
order to call _resumeUnsafeContinuation) reabstracted the block (e.g.
from @convention(block) to @substituted <T> () -> @out T for <()>). The
callee of the ObjC function, however, loaded the function from the block
as if it were not reabstracted (e.g. () -> ()).
On most platforms, that happened to work. On arm64e, that difference in
types caused in a difference in pointer signing, resulting in a failure
at runtime.
rdar://85526879
rdar://85526916
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
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
A conformance requirement on a concrete type parameter is redundant if the
concrete type conforms to the protocol.
The replacement path for the conformance rule is based on a concrete
conformance rule introduced by the property map. Since the concrete
conformance rule is not associated with a requirement ID, this would
normally muffle the redundancy warning, because we don't want to
suggest removing a rule that depends on a non-redundant, non-explicit
rule.
However, concrete conformance rules don't actually appear in the
minimal signature, so skip them when computing the set of non-redundant,
non-explicit rules to ensure that the original conformance requirement
is still diagnosed as redundant.
Previously, switches over extremely large integers (e.g. i832) were
emitted when emitting switches with many spare bits. Such switches
result in unfortunate downstream codegen.
Here, for large enums (currently, more than two words) the preexisting
EnumPayload::emitCompare function is used to compare each of the enum
cases in turn with the payload's value. The result is a series of
cond_br where the conditional is made by anding together word-size
chunks of the payload value with word-size chunks of each enum case's
tag, subject to masking.
rdar://83158525
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
