Don't include type-dependent operands in the argument list of the new keypath instruction.
Also enable the assert, which catches this problem, in release builds.
Fixes a compiler crash.
The problem with `is_escaping_closure` was that it didn't consume its operand and therefore reference count checks were unreliable.
For example, copy-propagation could break it.
As this instruction was always used together with an immediately following `destroy_value` of the closure, it makes sense to combine both into a `destroy_not_escaped_closure`.
It
1. checks the reference count and returns true if it is 1
2. consumes and destroys the operand
This is used for synthetic uses like _ = x that do not act as a true use but
instead only suppress unused variable warnings. This patch just adds the
instruction.
Eventually, we can use it to move the unused variable warning from Sema to SIL
slimmming the type checker down a little bit... but for now I am using it so
that other diagnostic passes can have a SIL instruction (with SIL location) so
that we can emit diagnostics on code like _ = x. Today we just do not emit
anything at all for that case so a diagnostic SIL pass would not see any
instruction that it could emit a diagnostic upon. In the next patch of this
series, I am going to add SILGen support to do that.
I am adding this instruction to express artificially that two non-Sendable
values should be part of the same region. It is meant to be used in cases where
due to unsafe code using Sendable, we stop propagating a non-Sendable dependency
that needs to be made in the same region of a use of said Sendable value. I
included an example in ./docs/SIL.rst of where this comes up with @out results
of continuations.
For now this will only be used for HopToMainActorIfNeeded thunks. I am creating
this now since in the past there has only been one option for creating
thunks... to create the thunk in SILGen using SILGenThunk. This code is hard to
test and there is a lot of it. By using an instruction here we get a few benefits:
1. We decouple SILGen from needing to generate new kinds of thunks. This means
that SILGenThunk does not need to expand to handle more thunks.
2. All thunks implemented via ThunkInst will be easy to test in a decoupled way
with SIL tests.
3. Even though this stabilizes the patient, we still have many thunks in SILGen
and various parts of the compiler. Over time, we can swap to this model,
allowing us to hopefully eventually delete SILGenThunk.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
If a protocol does not inherit Sendable, we still say that the
existential type is Sendable in Swift 5 mode. Make sure this
doesn't crash the SIL specializer.
Fixes https://github.com/swiftlang/swift/issues/75728
Cloning blocks might split CFG edges which can "convert" terminator result arguments to phi-arguments.
In this case a borrowed-from instruction must be inserted.
Fixes a SIL verifier crash caused by SimplifyCFG's jump threading.
rdar://129187525
It indicates that the value's lifetime continues to at least this point.
The boundary formed by all consuming uses together with these
instructions will encompass all uses of the value.
It seems really unfortunate that we use SILCloner to, basically,
implement a recursive visitor of the types used in a SIL function,
but apparently it's what we do.
Fixes#72117.
When cloning SIL, it's OK for conformances to Copyable or Escapable to
be carried-over as a builtin conformance, rather than an abstract
conformance.
This is a workaround for a bug introduced in
`6cd5468cceacc1d600c7dafdd4debc6740d1dfd6`.
resolves rdar://125460667
* Allow normal function results of @yield_once coroutines
* Address review comments
* Workaround LLVM coroutine codegen problem: it assumes that unwind path never returns.
This is not true to Swift coroutines as unwind path should end with error result.
Renamed "getUsesMoveableValueDebugInfo" to "usesMoveableValueDebugInfo".
Clarifies the predicate from "does the receiver have the
usesMoveableValueDebugInfo field set?" to "does the receiver use moveable
value debug info?".
