- 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
The locations stored in .swiftsourceinfo included the presumed file,
line, and column. When a location is requested it would read these, open
the external file, create a line map, and find the offset corresponding
to that line/column.
The offset is known during serialization though, so output it as well to
avoid having to read the file and generate the line map.
Since the serialized location is returned from `Decl::getLoc()`, it
should not be the presumed location. Instead, also output the line
directives so that the presumed location can be built as per normal
locations.
Finally, move the cache out of `Decl` and into `ASTContext`, since very
few declarations will actually have their locations deserialized. Make
sure to actually write to that cache so it's used - the old cache was
never written to.
mismatch.
If there's an error in property wrapper application, the backing property
wrapper type request will return a null type, which would cause the compiler
to crash because most error recovery code expects ErrorType. If the wrapper
application has an error, use the interface type of the parameter instead.
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 "unsafe" @Sendable parameters, indicated by the
hidden @_unsafeSendable parameter attribute. Closure arguments to such
parameters are treated as @Sendable within code that has already
adopted concurrency, but are otherwise enert, allowing them to be
applied to existing concurrency-related APIs to smooth the transition
path to concurrency.
Additionally, introduce the notion of an "unsafe" @MainActor closure,
for cases where we have determined that the closure will execute on
the main actor but it (also) isn't part of the type system.
Pattern-match uses of the Dispatch library's DispatchQueue to infer
both kinds of "unsafe" as appropriate, especially (e.g.) matching the pattern
DispatchQueue.main.async { ... }
to treat the closure as unsafe @Sendable and @MainActor, allowing such
existing code to better integrate with concurrency.
Implements rdar://75988966.
Implicitly add the @completionHandlerAsync attribute for ObjCMethodDecl
that have a completion handler. Adds a link from the non-async to the
async function for use in diagnostics and refactorings.
Resolves rdar://74665226
Don't treat `actorIndependent(unsafe)` as its own kind of isolation.
It was only really used as a bring-up hack to break the isolation model,
but shouldn't be in the user model of the language and causes
complications to the implementation.
The basic rule is that the protocol requirement
describes the maximal set of effects that the
property is allowed to have. Thus, witnesses
must have the same or fewer effects specifiers
on the getter.
For class inheritance overrides, you can remove
effects freely, as long as you stay within
the bounds of the normal override restrictions.
But, you cannot override with more effects than
the base member has. Same goes for protocol
member overrides.
Furthermore, we disallow key paths to effectful
properties/subscripts, which also cannot be @objc.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
The Actor protocol is used only to describe actors. When a protocol's
Self type conforms to the actor protocol, any instance declarations on
the protocol or extensions thereof are considered to be actor-isolated
to 'self'.
Because the instance requirements of such a protocol are
actor-isolated to 'self', they can be witnessed by actor-isolated
instance declarations on an actor type. For example:
```swift
protocol P: Actor {
func f() // okay, actor-isolated to self
}
extension P {
func g() { f() } // okay, actor-islated to self
}
actor MyActor: P {
func f() { } // okay, witnesses actor-isolated requirement
}
```
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.
The backs out of some early decisions we made about actor layout
that we don't need. Custom actors will use a different approach.
This should suffice for the remainder of rdar://70146827.
For example 'SourceFile' can handle all operations inside
'getSerializedLocs()', but it unnecessarily loads source content in a
new buffer, and resolve 'SourceLoc' from the line and the column.
And the result is completely useless.
rdar://problem/75010520
With "unsafe" global actor isolation, we only enforce actor isolation
when interacting with other explicitly-isolated code. This allows some
code to be annotated with, e.g., `@MainActor(unsafe)` so that users
who opt into concurrency get proper diagnostics, but existing code
does not change.
47b068d445 output a diagnostic if a
deserialized decl was invalid (checking `Decl::isInvalid`). It had two
major issues:
1. It incorrectly output diagnostics for valid modules
2. It did not catch call invalid declarations
(1) is caused by `isInvalid` falling back to checking the storage for
accessors when the interface type hasn't already been computed (a
fallback to prevent a cycle due to `SimpleDidSetRequest` typechecking
the body). Since the `VarDecl` hasn't finished deserializing, it returns
`true` for its `isInvalid` check (even though it would later return
`false`).
For (2), only `ValueDecl`s would ever be invalid, since other
declarations use a bit in `Decl` to check for validity. As that's not
serialized, those would always be valid in deserialization.
To avoid both these issues, instead output a flag for each declaration
representing whether it is invalid (or not). Read that during
deserialization and output a diagnostic if it is invalid. To be extra
sure that a diagnostic is always output on an error, also output one
when deserializing any `ErrorType`. This ensures that SILGen does not
run when allowing errors (and an error is present), as it is likely to
crash when presented with an invalid AST.
Resolves rdar://74541834
`SourceEntityWalker` had an unbalanced `walkToDeclPre` and
`walkToDeclPost`, ie. `walkToDeclPost` could be called even though
`walkToDeclPre` was not. Specifically, this would occur for both
`OperatorDecl` and `PrecedenceGroupDecl` declarations.
These could both be added to the `if` in `walkToDeclPost`, but this
seems fairly errorprone in general - especially as new decls are added.
Indeed, there's already declarations that are being skipped because they
aren't explicitly tested for in `walkToDeclPre`, ie.
`PatternBindingDecl`.
Instead of skipping if not explcitly handled, only skip running the
`SEWalker` walk methods if the declaration is implicit (and not a
constructor decl, see TODO). This should probably also always visit
children, with various decls changed to become implicit (eg.
TopLevelCodeDecl), but we can do that later - breaks too many tests for
now.
This change exposed a few parameter declarations that were missing their
implicit flag, as well as unbalanced walk methods in `RangeResolver`.
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.
