PredictableMemoryAccessOptimizations has become unmaintainable as-is.
RedundantLoadElimination does (almost) the same thing as PredictableMemoryAccessOptimizations.
It's not as powerful but good enough because PredictableMemoryAccessOptimizations is actually only needed for promoting integer values for mandatory constant propagation.
And most importantly: RedundantLoadElimination does not insert additional copies which was a big problem in PredictableMemoryAccessOptimizations.
Fixes rdar://142814676
This test was failing in some configurations due to missing availability.
Address it in the same manner as other distributed tests do, by setting
a target triple with Swift 5.7.
Fixes rdar://144229403.
When calling a distributed function for an actor that might not be local,
the call can throw due to the distributed actor system producing an
error. The function might, independently, also throw. When the
function uses typed throws, we incorrectly treated the call is if it
would always throw the error type specified by the function. This
leads to incorrectly accepting invalid code, and compiler crashes in
SILGen.
The change here is to always mark calls to distributed functions
outside the actor as "implicitly throwing", which makes sure that we
treat the call sites as throwing 'any Error'. The actual handling of
the typed throw (from the local function) and the untyped throw (from
the distributed actor system) occurs in thunk generation in SILGen,
and was already handled correctly.
Fixes rdar://144093249, and undoes the ban introduced by rdar://136467528
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.
