They don't yield a correct error type as we didn't implement it, so
rather allow it and risk crashes, ban it until we get the time to
implement it.
The real solution is to adjust typed throws error inference to do an
union of the thrown error of the func and the type thrown by the
distributed actor system remote call -- which today always would be (E |
Error) -> Error...
We could add a new associated type to DAS and then we could make it more
proper...
resolves rdar://136467528
This is a crucial fix without which we can crash on some distributed
protocol declarations with @Resolvable. We cannot "just" use a String to
represent the "fake base" of the thunks, and must instead find the
$Target macro generated type and use it as the base of the thunk's
mangling.
Calls are made in such way that record for the protocol requirement:
`$s4main28GreeterDefinedSystemProtocolP5greetSSyYaKFTEHF` points at
`$$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTE` which makes a
dispatch through the _apropriate_ witness table.
And the record for the $witness named e.g.
`$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTEHF` points to
`$s4main28GreeterDefinedSystemProtocolPAA11Distributed01_F9ActorStubRzrlE5greetSSyYaKFTE`
which is an extension method: `distributed thunk (extension in main):main.GreeterDefinedSystemProtocol< where A: Distributed._DistributedActorStub>.greet() async throws -> Swift.String`,
this very specific design allows us to call the "right method" on the
recieving end of a remote call where we do not know the recipient type.
Previously we would not propagate those into the generated distributed
actor, making a lot of generic distributed actor protocols impossible to
express.
We indeed cannot handle protocols WITHOUT primary associated types, but
we certainly can handle them with!
This resolves rdar://139332556
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Use the `%target-swift-5.X-abi-triple` substitutions to compile the tests for
deployment to the minimum OS versions required for the APIs used in the tests,
instead of disabling availability checking.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
The isolation checker was assuming that one can only be isolated to a
specific var, but that's not true for distributed actors -- because the
default parameter emitted by #isolation is a method call -- converting
the self into an any Actor.
We must handle this in isolation checker in order to avoid thinking
we're crossing isolation boundaries and making methods implicitly async
etc, when we're actually not.
resolves rdar://131874709
It cannot be used for executing general-purpose work, because such function would need to have a different signature to pass isolated actor instance.
And being explicit about using this method only for deinit allows to use object pointer for comparison with executor identity.
