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.
When scanning swift modules and constructing their build commands, there
is no need to pass any external plugin search paths if there are no macro
dependencies for the module.
rdar://135221984
Adds sections `__TEXT,__swift_as_entry`, and `__TEXT,__swift_as_ret` that
contain relative pointers to async functlets modelling async function entries,
and function returns, respectively.
Emission of the sections can be trigger with the frontend option
`-Xfrontend -enable-async-frame-push-pop-metadata`.
This is done by:
* IRGen adding a `async_entry` function attribute to async functions.
* LLVM's coroutine splitting identifying continuation funclets that
model the return from an async function call by adding the function
attribute `async_ret`. (see #llvm-project/pull/9204)
* An LLVM pass that keys off these two function attribute and emits the
metadata into the above mention sections.
rdar://134460666
For the purposes of availability calculations, direct use of
`llvm::VersionTuple` and `VersionRange` is discouraged, since these fundamental
version representations are divorced from their context. For example, comparing
an iOS platform version to a visionOS platform version is invalid since the
versioning systems of the two platforms differ. Although visionOS inherits
avialability from iOS, an iOS version must be converted to a visionOS version
prior to comparison. In the future, `AvailabilityContext` can be enriched to
carry the information necessary to verify that its algebraic operations are
being performed on compatible values.
NFC.
`UnavailabilityReason` does not live up to its name because it only models
potential unavailability due to an unmet OS version requirement. It does not
model unavailability caused by explicit annotation, language mode requirements,
obsoletion, etc. `AvailabilityContext` already models an OS version
requirement, so use it instead.
NFC.
An `AvailabilityContext` represents an abstract version range in which
something is available. In the future, these version ranges may not necessarily
always correspond to operating system version ranges.
NFC.
SE-0364 was amended to allow same-package conformances to be considered
non-retroactive. The logic for that ammendment was implemented in Swift 6.0,
but the diagnostics were not updated.
Resolves rdar://133423931.
Some invalid specializations were previously allowed by the compiler
and we found some existing code that used that (albeit invalid) syntax,
so we need to stage that error as a warning until Swift 6 language mode
to avoid source compatibility break.
Resolves: rdar://134740240
