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.
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.
