This attribute is designed for let-bound variables whose initializing
assignment is synthesized by the compiler. This assignment is
expected to happen at some point before DefiniteInitialization has
run, which is the pass that verifies whether the compiler truly
initialized the variable.
I generally expect that this will never be a user-facing feature, and
that the synthesized assignment happens in SILGen.
Enables SE-0348 `buildPartialBlock` feature by default. The frontend flag is kept for compatibility with existing clients, but is now ineffective.
Also includes some improved error messages for invalid result builder call sites.
In the replacement of the escaping-use restriction with
flow-isolation, I hadn't accounted for all of the situations
where the isolation changes would break backwards compatability
with Swift 5.5 programs. The escaping-use restriction permitted
a lot of very unsafe things with warnings that it would become
an error in Swift 6.
With the introduction of flow-isolation, it was a bit tricky to
get the right warnings back in place, while not unnessecarily
warning about property accesses that might actually be OK. There
is a very careful coordination between the type-checker and
the flow-isolation pass.
While I had done these downgrades for deinits, I also needed to
do them for inits as well, because member accesses to isolated
methods within actor initializer were still getting rejected
as an error. This patch should be pretty solid now.
fixes rdar://90595278
This effectively reverts 6823744779
The blanket removal of isolation in default-value expressions had
unintented consequences for important workflows. It's still
a problem that needs to be addressed, but we need to be more precise
about the problematic situations.
The previous warning "must be explicitly marked as 'any'" isn't clear if
you don't already know the feature, this new phrasing should make it
clearer by including the correct spelling of the type as an example.
Fixes rdar://90384448
* [Distributed] dist actor always has default executor (currently)
* [Distributed] extra test for missing makeEncoder
* [DistributedDecl] Add DistributedActorSystem to known SDK types
* [DistributedActor] ok progress on getting the system via witness
* [Distributed] allow hop-to `let any: any X` where X is DistActor
* [Distributed] AST: Add an accessor to determine whether type is distributed actor
- Classes have specialized method on their declarations
- Archetypes and existentials check their conformances for
presence of `DistributedActor` protocol.
* [Distributed] AST: Account for distributed members declared in class extensions
`getConcreteReplacementForProtocolActorSystemType` should use `getSelfClassDecl`
otherwise it wouldn't be able to find actor if the member is declared in an extension.
* [Distributed] fix ad-hoc requirement checks for 'mutating'
[PreChecker] LookupDC might be null, so account for that
* [Distributed] Completed AST synthesis for dist thunk
* [Distributed][ASTDumper] print pretty distributed in right color in AST dumps
* wip on making the local/remote calls
* using the _local to mark the localCall as known local
* [Distributed] fix passing Never when not throwing
* fix lifetime of mangled string
* [Distributed] Implement recordGenericSubstitution
* [Distributed] Dont add .
* [Distributed] dont emit thunk when func broken
* [Distributed] fix tests; cleanups
* [Distributed] cleanup, move is... funcs to DistributedDecl
* [Distributed] Remove SILGen for distributed thunks, it is in Sema now!
* [Distributed] no need to check stored props in protocols
* remote not used flag
* fix mangling test
* [Distributed] Synthesis: Don't re-use AST nodes for `decodeArgument` references
* [Distributed] Synthesis: Make sure that each thunk parameter has an internal name
* [Distributed/Synthesis] NFC: Add a comment regarding empty internal parameter names
* [Distributed] NFC: Adjust distributed thunk manglings in the accessor section test-cases
* cleanup
* [Distributed] NFC: Adjust distributed thunk manglings in the accessor thunk test-cases
* review follow ups
* xfail some linux tests for now so we can land the AST thunk
* Update distributed_actor_remote_functions.swift
Co-authored-by: Pavel Yaskevich <xedin@apache.org>
There are three kinds of invariant 'Self' uses here:
- 'Self' appears as the left hand side of a same-type requirement between type parameters
- 'Self' appears as a structural component of the right hand side of a concrete type requirement
- 'Self' appears as a structural component of the right hand side of a superclass requirement
My previous fix only handled the first case. Generalize it to handle all three.
Fixes rdar://problem/74944514.
This PR implements support for `buildPartialBlock` as proposed in https://forums.swift.org/t/pitch-buildpartialblock-for-result-builders/55561. This is similar to the existing support for `buildBlock(combining:into:)` except that it also checks for availability when deciding whether to fall back to plain old `buildBlock`.
> In the result builder transform, the compiler will look for static members `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)` in the builder type. If the following conditions are met:
> - Both methods `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)` exist.
> - The availability of the enclosing declaration is greater than or equal to the availability of `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)`.
When there's no available `buildPartialBlock` to call and there's no `buildBlock`, emit a diagnostic:
```console
result builder 'Builder' does not implement any 'buildBlock' or a combination of 'buildPartialBlock(first:)' and 'buildPartialBlock(accumulated:next:)' with sufficient availability for this call site
```
- have public visibility
- have at most one back deployment version per-platform
- specify an introduced version for each platform with a back deployment version using @available
- have a back deployment version that is greater than the introduced version
- not have conflicting attributes like @_alwaysEmitIntoClient
Refactor to share code with type checking for @_originallyDefinedIn which has overlapping diagnostics.
This enables support for inference in initializers of generic types
and in `case`s of generic enums e.g.
```
struct S<T> {
init(_: T = 42) {}
}
enum E<T: Collection> {
case test(_: T = [42])
}
```
Adds support for parameter types like `[T?]` or `[(T, U?)]`,
and relaxes restriction on same-type generic parameters.
A same-type requirement is acceptable if it only includes
in-scope generic parameters and concrete types i.e. `T.X == Int`
if accepted if `T` is referenced only by a parameter default
expression is being applied to.
Only warn when using a type alias if the underlying type is directly
a constraint type. Also check the underlying type for missing 'any'
if the underlying type is not directly a constraint type.
When compiling with Swift 6 mode, but using a serialized module
that is using Swift 5 that contains a struct with global-actor
isolation on its stored property, we should not emit an error
for that stored property. Only a warning was emitted when compiling
that module, but the checks here were treating that module as being
type-checked again under a Swift 6 world.
Based on the review discussion of this proposal, prohibit the use of
opaque parameters in "consuming" positions of function types, as we did
with opaque result types in SE-0328.
SE-0338 changed the execution of non-actor async functions
so that they always hop to the generic executor, but some
functions need a way to suppress this so that they inherit
the caller's executor.
The right way to implement this is to have the caller pass
down the target executor in some reliable way and then
switch to it in all the appropriate places in the caller.
We might reasonably be able to build this on top of isolated
parameters, using some sort of default argument, or we might
need a wholly novel mechanism.
But those things are all ABI-breaking absent some sort of
guarantee about switching that we probably don't want to make,
and unfortunately we have functions in the library which we
need to export that need to inherit executors. So in the
short term, we need some unsafe way of getting back to the
previous behavior.
