When we run RegionAnalysis, since it uses RPO order, we do not visit dead
blocks. This can create a problem when we emit diagnostics since we may merge in
a value into the region that was never actually defined. In this patch, if we
actually visit the block while performing dataflow, I mark a bit in its state
saying that it was live. Then when we emit diagnostics, I do not visit blocks
that were not marked live.
rdar://124042351
Before I couldn't do this since, @sil_isolated was not represented on
partial_applies. Since in the previous commit, I added support to the compiler
to represent this, I can now limit this query so now one can pass an actor
instance outside of its method to a nonisolated non-Sendable partial apply.
Since it is Sendable, it is always safe to do this since we are passing the
actor.
rdar://123881277
Previously, we assumed we would always have a partial_apply. In the case where
we do not capture any values this is not true since we instead have a
thin_to_thick_function.
Just noticed this while trying to write some tests that validated that we were
properly ignoring strict-concurrency features. I put in asserts to validate that
when either of these are enabled, we have strict-concurrency set as well.
Moved out of MemoryLocations.h and merged the implementations of <<,
keeping the version from MemoryLocations with its brackets and commas
available via a flag but defaulting the implementation previously in the
header.
We purposely do not treat a PartitionOpKind::Transfer as a require since that
would cause us to error when we weakly transfer the same parameter multiple
times to the same function. This is safe since all of the function parameters
will be in the same region.
To ensure that this fixed the multiple strong transferring issue (which is
exposed by requiring before transferring), I also had to muck around a little
with how we emit errors to ensure that we emit errors if the transfer
instruction is also the require.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
I thought that we would never actually hit this test case, but since we do not
have opaque values this pattern is treated like a projection in certain cases. I
updated the code as appropriate and added a test.
We should make this as a transfer... but this is just temporary until I get
around to it. For now this is always an out parameter, so we should be safe.
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.
