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.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
This ensures that when we process, we consider load/load_borrow's result to be
equivalent to its operand. This ensures that a load/load_borrow cannot act as a
use of its operand preventing spurious diagnostics.
The reason why we do this is that we want to treat this as a separate value from
their operand since they are the result of defining a new value.
This has a few nice side-effects, one of which is that if a let results in just
a begin_borrow [var_decl], we emit names for it.
I also did a little work around helping variable name utils to lookup names from
applies that are fed into a {move_value,begin_borrow} [var_decl] which then has
the debug_value we are searching for.
To be more specific this means that either:
1. The use is actually isolated to the same actor. This could mean that the
use is global actor isolated to the same function.
2. The use is nonisolated but is executing within a function that is globally
isolated to the same isolation domain.
rdar://123474616
I am doing this since it isn't always going to be an access. We may not have
memory. We are talking about uses here!
I was able to just use sed so it was an easy fix.
The reason why I am doing this is that:
1. function_extract_isolation can take as a parameter a non-Sendable function
today in SIL so in such a case, we crash.
2. It returns an Optional<any Actor> which always must be Sendable.
So it makes sense for it to just require that its non-Sendable parameter not be
transferred at that point.
This assert validates that look through parameters only have a single operand
(the one we are going to lookthrough). It did not take into account though that
some of these lookthrough instructions /do/ have type dependent operands (which
we should ignore for the assert). I changed the assert to ignore those.
Noncopyable types cannot be substituted for an unconstrained generic
parameter, as it will have a Copyable conformance on it.
This test should be refactored to use a concrete function like
`transferMoveOnlyStruct` instead of the generic. But its not obvious to
me the best way to update this test.
I was correct that it is lookthrough, but it has multiple parameters, so the
normal "baked" implementation cannot be used since the "baked" implementation
assumes that any insts it handles has a single operand.
I also made ref_to_unmanaged and unmanaged_to_ref look through. They should have
always been look through, but I believe early on they were marked assign and I
never touched fixed it. To get the test for strong_copy_unmanaged_value to work,
I needed them to obey these semantics so I fixed them at the same time.
Specifically, if we access a Sendable type from a ref_element_addr and the field
is mutable, we need to treat the use as a require since we could race on writing
to the field. If the field is a let though (and thus immutable), we can still
ignore it.
I also used this as an opportunity to add SIL tests for ref_element_addr.
