rdar://163631865
Under certain circumstances the same symbol can be used for different implementations of the forwarders.
The forwarders themselves are already emitted with "internal" LLVM linkage, but some particularities in
the mapping from SILLinkage to LLVM linkage caused async function pointers to partial apply forwarders
to be emitted with linkonce_odr instead, which caused the wrong forwarder to be called at runtime, causing
unexpected behavior and crashes.
We generate public metadata lazily which implies it could be emitted into a
different module. If we emit metadata for a public type into a module
other than its "home module" apply "shared" linkage.
This sanitizer adds MTE (memory tagging extension) checks to stack
variable accesses. Enablement simply requires setting an attribute on
function definitions, and the instrumentation is added by LLVM.
The corresponding swift-driver change is at:
https://github.com/swiftlang/swift-driver/pull/2016.
rdar://161721201
We had introduced coroframe_entry downstream while the upstream proposal
was discussed. It has since been merged upstream, so this commit changes
the code to use the upstream intrisic, avoiding a binary incompatibility
in the IR w.r.t. upstream.
`irgen::addGenericRequirements` will later filter out Copyable
and Escapable requirements, so this field's count isn't accurate
if it's using the pre-filtered number.
This should in theory only affect the metadata emission for keypaths,
specifically, the caller `IRGenModule::getAddrOfKeyPathPattern`.
Previously debug info made not difference between an existential type and a
protocol type. This caused us to loose typealiases such as
typealias Alias = ProtocolType
in the debug info.
rdar://161134092
Before this change, we were sometimes using introductory platform version as the starting version where
a symbol is considered belonging to the original binary. However, this is insufficient
because backdeploying to a platform version prior to a symbol's introductory version can happen. When it
happens, we should expect the moved symbol to be found in the moved-from library, not the moved-to one. Expecting
the symbol to be found in the moved-to library can lead to crasher.
Resolves: rdar://159408187
All symbols are private (as in the API descriptor) if the library level
is more restricted than `LibraryLevel::API`.
Resolves rdar://164901718
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
The previous code would not detect Container<T>.NonFixed but only NonFixed<T>.
For code size reasons we want to use the generic value witness functions rather than specialized ones in specialized metadata.
We cannot use 'static' linkage for something that points into the
ASTContext, because there might be more than one ASTContext in a
single process.
Also, fix the spelling mistake in a related function name.
We currently disallow these by deleting them in the `swift` namespace.
This approach has several loopholes, all of which ultimately work
because we happen to define specializations of `simplify_type` for
`swift::Type`:
* `llvm::isa/cast/dyn_cast`. The deleted partial specializations will
not be selected because they are not defined in the `llvm` namespace.
* The argument is a non-const `Type`. The deleted function templates
will not be selected because they all accept a `const Type &`, and
there is a better `Y &Val` partial specialization in LLVM.
* Other casting function templates such as `isa_and_nonull` and
`cast_if_present` are not deleted.
Eliminate these loopholes by instead triggering a static assertion
failure with a helpful message upon instantiation of `CastInfo` for
`swift::Type`.
