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.
Swift allows a method override to be more visible than the base method.
In practice, this means that since it might be possible for client
code to see the override but not the base method, we have to take
extra care when emitting the override.
Specifically, the override always receives a new vtable entry, and
a vtable thunk is emitted in place of the base method's vtable entry
which re-dispatches via the override's vtable entry.
This allows client code to further override the method without any
knowledge of the base method's vtable entry, which may be inaccessible
to the client.
In order for the above to work, three places in the code perform
co-ordinated checks:
- needsNewVTableEntry() determines whether the override is more
visible than the base, in which case it receives a new vtable
entry
- SILGenModule::emitVTableMethod() performs the same check in order
to emit the re-dispatching vtable thunk in place of the base
method's entry
- in the client, SILVTableVisitor then skips the base method's
vtable entry entirely when emitting the derived class, since no
thunk is to be emitted.
The problem was that the first two used effective access (where
internal declarations become public with -enable-testing), while
the last check used formal access. As a result, it was possible
for the method override vtable entry to never be emitted in the
client.
Consistently using either effective access or formal access would
fix the problem. I fixed the first two to rely on formal access;
the reason is that using effective access makes vtable layout
depend on whether the library was built with -enable-testing or
not, which is undesirable since we do not want -enable-testing to
impact the ABI, even for non-resilient frameworks.
Fixes rdar://problem/74108928.
Initializers are actor-isolated when they are part of an actor or have
a global actor. However, uses of actor initializers need to be treated
as cross-actor references so we proper `ConcurrentValue` checking for
values passed into the initializer.
Fixes rdar://74064751.
A marker protocol is a protocol with no requirements and with no ABI
footprint. They can be used to indicate semantics, only, and one can
never have values of a marker protocol type.
We still mangle marker protocols when they are used as generic
requirements, because they are a distinguishing characteristic for
overloading, but "no ABI footprint" means no protocol descriptors,
conformance descriptors, or dynamic discovery of any kind.
Introduce `@concurrent` attribute on function types, including:
* Parsing as a type attribute
* (De-/re-/)mangling for concurrent function types
* Implicit conversion from @concurrent to non-@concurrent
- (De-)serialization for concurrent function types
- AST printing and dumping support
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
