- Introduce an UnownedSerialExecutor type into the concurrency library.
- Create a SerialExecutor protocol which allows an executor type to
change how it executes jobs.
- Add an unownedExecutor requirement to the Actor protocol.
- Change the ABI for ExecutorRef so that it stores a SerialExecutor
witness table pointer in the implementation field. This effectively
makes ExecutorRef an `unowned(unsafe) SerialExecutor`, except that
default actors are represented without a witness table pointer (just
a bit-pattern).
- Synthesize the unownedExecutor method for default actors (i.e. actors
that don't provide an unownedExecutor property).
- Make synthesized unownedExecutor properties `final`, and give them
a semantics attribute specifying that they're for default actors.
- Split `Builtin.buildSerialExecutorRef` into a few more precise
builtins. We're not using the main-actor one yet, though.
Pitch thread:
https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425
Add a feature for this new attribute, and make sure we use the feature
guard for functions that use it, e.g., the new `async`.
Finishes rdar://76927008.
Since 9ba892c we always transform `CurrentType` in `ASTPrinter` to be an interface type.
This causes issues when the variable type is a generic parameter type. Previously we had `CurrentType` set to a `PrimaryArchetypeType`. With the fix in d93ae06, we are mapping the archetype out of context to a `GenericParamType`. A `GenericParamType`, however, can’t have members, so we’re hitting an assertion when creating a `TypeTransformContext`. Since the entire type transformation in `printTransformedTypeWithOptions` is only affecting type members, we should be able to safely skip over the transformation if `CurrentType` can’t have any members.
Fixes rdar://76750555 [SR-14497]
The start and end lines were only used while constructing the comments,
so move the line tracking into that method instead of storing it in each
comment.
Since 9ba892c5af we always transform `CurrentType` in `ASTPrinter` to be an interface type.
This causes issues for variables that whose type is a protocol. Previously, when printing the type, we had `CurrentType` set to an `OpenedArchetypeType`. Now we replace the archetype by a `GenericTypeParamType`, which may not have members, so we are hitting an assertion in `ASTPrinter.cpp:270`.
To resolve this, replace any `OpenedArchetypeType`s with their protocol type before calling `mapTypeOutOfContext`.
Resolves rdar://76580851 [SR-14479]
Since 865e80f9c4 we are keeping track of internal closure labels in the closure’s type. With this change, wer are also serializing them to the swiftmodules.
Furthermore, this change adjusts the printing behaviour to print the parameter labels in the swiftinterfaces.
Resolves rdar://63633158
When printing a type in type through `ASTPrinter::printTransformedTypeWithOptions`, we are removing any contextual types by mapping the type out of context. However, when substituting `Self` (or any other type member) with their concrete type from `CurrentType`, we might re-introduce contextual types.
To fix this, make sure that `CurrentType` is always an interface type that has all contextual types removed.
Fixes rdar://76021569
- stop storing the parent task in the TaskGroup at the .swift level
- make sure that swift_taskGroup_isCancelled is implied by the parent
task being cancelled
- make the TaskGroup structs frozen
- make the withTaskGroup functions inlinable
- remove swift_taskGroup_create
- teach IRGen to allocate memory for the task group
- don't deallocate the task group in swift_taskGroup_destroy
To achieve the allocation change, introduce paired create/destroy builtins.
Furthermore, remove the _swiftRetain and _swiftRelease functions and
several calls to them. Replace them with uses of the appropriate builtins.
I should probably change the builtins to return retained, since they're
working with a managed type, but I'll do that in a separate commit.
If have a function that takes a trailing closure as follows
```
func sort(callback: (_ left: Int, _ right: Int) -> Bool) {}
```
completing a call to `sort` and expanding the trailing closure results in
```
sort { <#Int#>, <#Int#> in
<#code#>
}
```
We should be doing a better job here and defaulting the trailing closure's to the internal names specified in the function signature. I.e. the final result should be
```
sort { left, right in
<#code#>
}
```
This commit does exactly that.
Firstly, it keeps track of the closure's internal names (as specified in the declaration of `sort`) in the closure's type through a new `InternalLabel` property in `AnyFunctionType::Param`. Once the type containing the parameter gets canonicalized, the internal label is dropped.
Secondly, it adds a new option to `ASTPrinter` to always try and print parameter labels. With this option set to true, it will always print external paramter labels and, if they are present, print the internal parameter label as `_ <internalLabel>`.
Finally, we can use this new printing mode to print the trailing closure’s type as
```
<#T##callback: (Int, Int) -> Bool##(_ left: Int, _ right: Int) -> Bool#>
```
This is already correctly expanded by code-expand to the desired result. I also added a test case for that behaviour.
Introduce the notion of global actor-qualified function types, e.g.,
@MainActor () -> Void
to describe synchronous functions that must execute on a particular
global actor.
Extend the checks for marker protocols and rethrows protocols to ensure
that we #if out more code that relies on them in module interface
generation. This makes the _Concurrency module parseable by much older
compilers.
Fixes rdar://75291705.
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
When a derived class does not inherit a designated initializer from
its base class, we override the designated initializer's vtable
entry with a stub which traps with a fatal error.
The stub cannot be called and clients do not need to be aware of
its existence, so don't print it at all in the module interface.
Fixes rdar://problem/71122015 / https://bugs.swift.org/browse/SR-13832.
* Make the `build-parser-lib` script more flexible on how it finds the llvm source path
* Make sure `swift-syntax-parser-test` can be built even though the script disables building for testing
* Fix a linker error for parser-only build
Thanks to a great idea from Slava, simplify the printing of marker
protocols in Swift interfaces while maintaining backward compatibility.
For compilers that cannot handle marker protocols, print a typealias
to `Any` instead, which is a good stand-in for just about everything.
This patch softly updates the spelling of actors from `actor class` to
`actor`. We still accept using `actor` as a modifying attribute of
class, but emit a warning and fix-it to make the change.
One of the challenges that makes this messier is that the modifier list
can be in any order. e.g, `public actor class Foo {}` is the same as
`actor public class Foo {}`.
Classes have been updated to include whether they were explicitly
declared as an actor. This change updates the swiftmodule serialization
version number to 0.591. The additional bit only gets set of the class
declaration was declared as an actor, not if the actor was applied as an
attribute. This allows us to correctly emit `actor class` vs `actor`
emitting the code back out.
When generating a module interface, emit `#if` around any declarations
that are tied to specific, named language features. This allows module
interfaces to be processed by older Swift compilers that do not
support these newer features, such as async/await or actors.
The amount of effort required to correctly handle a new kind of
feature varies somewhat drastically based on the feature itself. The
"simple" case is where a particular declaration can only exist if a
feature is available. For example, and `async` declaration is fairly
easy to handle; a `@_marker` protocol's conformances are not.
Fixes rdar://73326633.
