Initially this declaration is going to be used to determine
per-file default actor isolation i.e. `using @MainActor` and
`using nonisolated` but it could be extended to support other
file-global settings in the future.
Tweaked diagnostic to use a string instead of a type. Renamed the
feature in `FeatureAvailability.def` (and added the `TaskExecutor`
feature to 6.2). Also fixed the `swift_getActiveExecutor()`
function to return the main executor only when on the main thread.
rdar://141348916
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
It cannot be used for executing general-purpose work, because such function would need to have a different signature to pass isolated actor instance.
And being explicit about using this method only for deinit allows to use object pointer for comparison with executor identity.
[serialized_for_package] if Package CMO is enabled. The latter kind
allows a function to be serialized even if it contains loadable types,
if Package CMO is enabled. Renamed IsSerialized_t as SerializedKind_t.
The tri-state serialization kind requires validating inlinability
depending on the serialization kinds of callee vs caller; e.g. if the
callee is [serialized_for_package], the caller must be _not_ [serialized].
Renamed `hasValidLinkageForFragileInline` as `canBeInlinedIntoCaller`
that takes in its caller's SerializedKind as an argument. Another argument
`assumeFragileCaller` is also added to ensure that the calle sites of
this function know the caller is serialized unless it's called for SIL
inlining optimization passes.
The [serialized_for_package] attribute is allowed for SIL function, global var,
v-table, and witness-table.
Resolves rdar://128406520
This implements support for autoclosures, closures and local functions
nested within a pack iteration for loop.
The combination of explicit closure expressions and pack expansion
expressions still needs some work.
Fixes#66917.
Fixes#69947.
Fixes rdar://113505724.
Fixes rdar://122293832.
Fixes rdar://124329076.
a closure expression, then don't actually do it. The long term plan is
to actually do this, which should just be a matter of taking some of the
code out of reabstraction thunk emission and using it in prolog/epilog/return
emission. In the short term, the goal is just to get the conversion
information down to the closure emitter so that we can see that we're
erasing into an `@isolated(any)` type and then actually erase the
closure's isolation properly instead of relying on type-based erasure,
which can't handle parameter/capture isolation correctly.
The distributed-actor-as-actor conformance is synthesized by the
frontend, so make sure that when we access the API that exposes it
(asLocalActor), we be sure to mark the conformance as "used".
This is a very specific workaround for general problem with
compiler-synthesized conformances. SIL deserialization can bring in a
reference to a conformance late in the SIL pipeline, after the point at
which SILGen can create the conformance. We should be able to address
this systemically to remove the hack.
SILGen and IRGen would disagree on the return type of the
`swift_task_getMainExecutor()` runtime function if
`SILGenModule::getGetMainExecutor()` had ever been called. To address this,
consistently use the `buildMainActorExecutorRef` built-in and get rid of
`SILGenModule::getGetMainExecutor()`.
Resolves rdar://116472583
Because `CheckedContinuation` is not a @frozen struct we have
to use `Any` to store it in @block_storage indirectly. If the
flag is enabled, we'd emit a block storage with `Any` and
initialize the existential with stack allocated `CheckedContinuation`
formed from `UnsafeContinuation`. Inside of the completion handler
`Any` is going to be projected and cast back to `CheckedContinuation`.
The property descriptors of `@backDeployed` properties aren't available on OSes
prior to the "back deployed before" OS version, so the descriptors cannot be
referenced by clients that may run against older versions of the library
that defines the property.
See https://github.com/apple/swift/pull/59214 for prior art.
Resolves rdar://106517386
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.
Some notes:
1. I put in both a swiftpm like test case and a library evolution test case. I
also updated the moveonly_deinit serialization swift test to show that we
actually serialize the deinit.
2. I changed when we emit the deinit table to only be when we have a type with
an actual value type destructor. Notably this doesn't include classes today so
as a side-effect, we no longer attempt to devirtualize moveonly class deinits.
This doesn't affect anything we are trying to actually do since we do not
support noncopyable classes today. With that in mind, I changed one test that
was showing that deinit devirtualization worked to use a struct with deinit
instead of a class.
rdar://109679168
If a function body references a declaration with the `@_backDeploy(before:)` attribute and that function body will only execute on deployment targets for which the ABI version of the decl is available then it is unnecessary to thunk the reference to the decl. Function bodies that may be emitted into other modules (e.g. `@inlinable`) must always use the thunk.
Resolves rdar://90729799
If the emission of a function is delayed via `emitOrDelayFunction()`, then the function is recorded on a list of delayed functions. If the delayed function is later referenced, then the function moves from the delayed list to the "forced" list which will cause it to actually be emitted later. The implementation of `emitOrDelayFunction()` had a bug when called twice for the same delayable function - it would emit that function prematurely if the function moved to the forced list between the two invocations. Later, during forced function emission a multiple definitions of symbol diagnostic would be emitted since the function was not empty.
This issue could be triggered by `@_backDeploy` functions that have auxilary delayable helper functions (e.g. defer blocks). SILGen visits `@_backDeploy` functions twice (once for the copy of the function emitted into the client and once for the resilient copy of the function) so `emitOrDelayFunction()` is called twice for each of the helper functions and the helper functions could become referenced between the two calls.
The fix is to check for an existing entry in the forced functions list before delaying or emitting a delayable function.
Resolves rdar://102909684
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
