Ensure that context descriptor pointers are signed in the runtime by putting the ptrauth_struct attribute on the types.
We use the new __builtin_ptrauth_struct_key/disc to conditionally apply ptrauth_struct to TrailingObjects based on the signing of the base type, so that pointers to TrailingObjects get signed when used with a context descriptor pointer.
We add new runtime entrypoints that take signed pointers where appropriate, and have the compiler emit calls to the new entrypoints when targeting a sufficiently new OS.
rdar://111480914
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Unfortunately, I don't have reduced reproduction for the crash that motivated
this fix, but similar precautions are taken elsewhere when handling
PatternBindingDecls.
Suggesting the addition of an `@available` attribute on Linux and Windows is
inapprorpriate given that Swift is not ABI stable on those platforms.
Resolves rdar://107387133
This ensures SIL lowering will avoid generating code for unavailable global
vars when `-unavailable-decl-optimization=complete` is specfied.
Part of rdar://106674022
It turns out that we must allow declarations with `introduced:` availability
nested inside of other declarations that are `unavailable` in order to
influence weak linking. Stop diagnosing declarations as being more available
than their unavailable containers and revert some changes to availability
inference that were designed to avoid creating these nestings but caused
regressions for declarations marked `@_spi_available.`
Reverts parts of https://github.com/apple/swift/pull/64310,
https://github.com/apple/swift/pull/64015, and
https://github.com/apple/swift/pull/62900.
Previously, when creating availability attributes for synthesized declarations
we would identify some set of reference declarations that the synthesized
declaration should be as-available-as. The availability attributes of the
reference declarations would then be merged together to create the attributes
for the synthesized declaration. The problem with this approach is that the
reference declarations themselves may implicitly inherit availability from their
enclosing scopes, so the resulting merged attributes could be incomplete. The
fix is to walk though the enclosing scopes of the reference declarations,
merging the availability attributes found at each level.
Additionally, the merging algorithm that produces inferred availability
attributes failed to deal with conflicts between platform specific and platform
agnostic availability. Now the merging algorithm notices when platform agnostic
availability should take precedence and avoids generating conflicting platform
specific attributes.
Resolves rdar://106575142
When synthesizing a declaration and inferring its availability, the synthesized attribute should factor in unavailability of the parent declarations. This recently regressed with https://github.com/apple/swift/pull/63361. However, the previous implementation did not produce correct results, either, because the logic for merging availability attributes produced a non-sensical result when both `unavailable` and `introduced:` availability attributes were merged. For example, this was the result for the synthesized `unownedExecutor` property of an actor when the actor was marked unavailable:
```
@available(macOS, unavailable)
actor A {
// Incorrectly synthesized availability for `unownedExecutor` which results from merging
// the unavailability of the parent and the availability of the UnownedSerialExecutor type.
@available(macOS, unavailable, introduced: macOS 10.15)
@_semantics("defaultActor") nonisolated final var unownedExecutor: UnownedSerialExecutor { get }
}
```
This is fixed by omitting all version components from the synthesized attribute when the overall attribute kind is "unavailable".
Additionally, I discovered that the `concurrency_availability.swift` test case was no longer testing what it intended to test. The conformances to `Actor` for each `actor` in the test were no longer being synthesized and therefore `unownedExecutor` was not being synthesized. That was fixed by importing the `_Concurrency` module directly, which seems to be necessary because of the `-parse-stdlib` flag in the test.
Resolves rdar://106055566
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array.
But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global.
rdar://94185998
This reverts the revert commit df353ff3c0.
Also, I added a frontend option to disable this optimization: `-disable-readonly-static-objects`
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array.
But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global.
rdar://94185998
Previously, the availability checker has assumed that no code in a module is available on less than the minimum deployment target. In modules using library evolution, this is not actually true--certain function bodies can be inlined into modules with lower minimum deployment targets, where they can run against versions of the library that had lower minimum deployment targets. By failing to check for availability violations in these function bodies that relate to versions below the minimum deployment target, we can end up allowing inlinable code that doesn't compile with the correct runtime linkage or has other serious problems.
This commit lowers the root type refinement context's avialability to the value of the -target-min-inlining-version option (if provided) and then raises it again inside the bodies of functions whose implementations are not exposed to clients. This introduces some incorrect typechecking of declaration signatures, but we'll fix that in another commit.
report_fatal_error added a `const Twine &` overload a while ago, which
was fine since `const std::string &` was a better match.
`const std::string &` was recently removed, however, which then caused
an ambiguous match between `const Twine &` and `StringRef` overloads.
Add a frontend-only flag `-enable-experimental-back-deploy-concurrency`
to be used to stage in the back deployment of concurrency. At present,
all it does is lower the availability minimums for use of concurrency
features.
Instead of a new attribute `@completionHandlerAsync`, allow the use of
the existing `renamed` parameter of `@available` to specify the
asynchronous alternative of a synchronous function.
No errors will be output from invalid names as `@completionHandlerAsync`
had, but if a function is correctly matched then it will be used to
output warnings when using the synchronous function in an asynchronous
context (as before).
Resolves rdar://80612731
When witness tables for enums are instantiated at runtime via
swift::swift_initEnumMetadataMultiPayload
the witnesses
getEnumTagSinglePayload
storeEnumTagSinglePayload
are filled with swift_getMultiPayloadEnumTagSinglePayload (previously
getMultiPayloadEnumTagSinglePayload) and
swift_storeMultiPayloadEnumTagSinglePayload (previously
storeMultiPayloadEnumTagSinglePayload). Concretely, that occurs when
instantiating the value witness table for a generic enum which has more
than one case with a payload, like Result<T>. To enable the compiler to
do the same work, those functions need to be visible to it.
Here, those functions are made visible to the compiler. Doing so
requires changing the way they are declared and adding them to
RuntimeFunctions.def which in turn requires the definition of some
functions to describe the availability of those functions.
This allows programs to target older OSes while using Concurrency behind an availability check. When targeting older OSes, the symbols are weak-linked and the compiler will require the use of Concurrency features to be guarded by an availability check.
rdar://75850003
Previously, the availability was "Future", meaning that any features
that were gated to be available in "Swift 5.4" would only be used if the
target were the highest possible version number (like iOS 99). Here
that is fixed by using the OS versions that actually shipped with Swift
5.4.
rdar://75978438
