Motivated by need for protocol-based dynamic dispatch, which hasn't been possible in Embedded Swift due to a full ban on existentials. This lifts that restriction but only for class-bound existentials: Class-bound existentials are already (even in desktop Swift) much more lightweight than full existentials, as they don't need type metadata, their containers are typically 2 words only (reference + wtable pointer), don't incur copies (only retains+releases).
Included in this PR:
[x] Non-generic class-bound existentials, executable tests for those.
[x] Extension methods on protocols and using those from a class-bound existential.
[x] RuntimeEffects now differentiate between Existential and ExistentialClassBound.
[x] PerformanceDiagnostics don't flag ExistentialClassBound in Embedded Swift.
[x] WTables are generated in IRGen when needed.
Left for follow-up PRs:
[ ] Generic classes support
The reason why is that we want to distinguish inbetween SILFunction's that are
marked as unspecified by SILGen and those that are parsed from textual SIL that
do not have any specified isolation. This will make it easier to write nice
FileCheck tests against SILGen output on what is the inferred isolation for
various items.
NFCI.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
If a single native value is bridged multiple times, it cannot be
consumed without other changes. One option would be to copy it. The
other option is taken here: sink the destroy of the native value to
after the apply and have the outlined function take the value
guaranteed.
rdar://134198292
I thought `reverse(silFn)` would do a post-order walk, but I was wrong.
This patch cuts the number of iterations to propagate coldness from
3-4 down to 2 in a few of the simple regression test cases. At least on
macOS (as the stdlib can vary per platform).
This PR ensures library-evolution is enabled for Package CMO; without it,
it previously fell back to regular CMO, which caused mismatching serialization
attributes if importing another module that had Package CMO enbaled, causing
an assert fail for loadable types.
Resolves rdar://135308288
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
The old analysis pass doesn't take into account profile data, nor does
it consider post-dominance. It primarily dealt with _fastPath/_slowPath.
A block that is dominated by a cold block is itself cold. That's true
whether it's forwards or backwards dominance.
We can also consider a call to any `Never` returning function as a
cold-exit, though the block(s) leading up to that call may be executed
frequently because of concurrency. For now, I'm ignoring the concurrency
case and assuming it's cold. To make use of this "no return" prediction,
use the `-enable-noreturn-prediction` flag, which is currently off by
default.
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://133779160
In order for availability checks in iOS apps to be evaluated correctly when
running on macOS, the application binary must call a copy of
`_stdlib_isOSVersionAtLeast_AEIC()` that was emitted into the app, instead of
calling the `_stdlib_isOSVersionAtLeast()` function provided by the standard
library. This is because the call to the underlying compiler-rt function
`__isPlatformVersionAtLeast()` must be given the correct platform identifier
argument; if the call is not emitted into the client, then the macOS platform
identifier is used and the iOS version number will be mistakenly interpreted as
a macOS version number at runtime.
The `_stdlib_isOSVersionAtLeast()` function in the standard library is marked
`@_transparent` on iOS so that its call to `_stdlib_isOSVersionAtLeast_AEIC()`
is always inlined into the client. This works for the code generated by normal
`if #available` checks, but for the `@backDeployed` function thunks, the calls
to `_stdlib_isOSVersionAtLeast()` were not being inlined and that was causing
calls to `@backDeployed` functions to crash in iOS apps running on macOS since
their availability checks were being misevaluated.
The SIL optimizer has a heuristic which inhibits mandatory inlining in
functions that are classified as thunks, in order to save code size. This
heuristic needs to be relaxed in `@backDeployed` thunks, so that mandatory
inlining of `_stdlib_isOSVersionAtLeast()` can behave as expected. The change
should be safe since the only `@_transparent` function a `@backDeployed` thunk
is ever expected to call is `_stdlib_isOSVersionAtLeast()`.
Resolves rdar://134793410.
Also, move this rule from the computation of lowered captures in SIL,
to the computation of AST captures in Sema. This allows us to
correctly handle the case where an async function nests inside a
sync function. It also removes a special case that was added recently
to cope with a generic `self` type.
Fixes rdar://129366819.
Unknown uses of raw pointers should not result in bailing out when an
address is lexical--the destroy of the address will already not be
hoisted over any instructions which may access pointers. If the address
is not lexical however (such as any address when lexical lifetimes are
disabled), that rationale does not apply, so unknown uses of raw
pointers must cause hoisting to bail.
rdar://133969821
