Specifically, we write a string out like:
sil [isolation "$REPRESENTATION OF ISOLATION"] @function : $@convention(thin) ...
The idea is that by using a string, we avoid parsing issues of the isolation and
have flexibility. I left in the way we put isolation into the comment above
functions so I did not break any tests that rely on it. I also made it so that
we only accept this with sil tests that pass in the flag
"sil-print-function-isolation-info". I am going to for the next release put in a
full real implementation of this that allows for actor isolation to become a
true first class citizen in SIL. But for now this at least lets us write tests
in the short term.
Since this is temporary and behind a flag, I did not add support for
serialization since this is just for writing textual SIL tests.
(cherry picked from commit ee3027c2ca)
Conflicts:
lib/SIL/Parser/ParseSIL.cpp
This was fix was accidentally not include in the previous commit,
which breaks older .swiftinterface files without it:
commit 75ba7a845c
Merge: befc15e6dfd41c4d4cc9
Author: Andrew Trick <atrick@apple.com>
Date: Wed Mar 19 18:22:35 2025
Merge pull request #80064 from atrick/lifetime-inference
LifetimeDependence: implement strict type checking
The Protocol field isn't really necessary, because the conformance
stores the protocol. But we do need the substituted subject type
of the requirement, just temporarily, until an abstract conformance
stores its own subject type too.
Parameters of generic type need to be treated as potentially
addressable-for-dependencies, but we don't want callers using the generic
function with concrete types that are known not to be addressable-for-
dependencies to be overconstrained. In SILFunctionType lowering, lower
these dependencies distinctly as conditionally addressable, meaning that
the dependency on an argument depends on whether the concrete type of
that argument is (potentially) addressable-for-dependencies or not.
Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
Check if an operand's instruction has been deleted in `UseList.next()`.
This allows to delete an instruction, which has two uses of a value, during use-list iteration.
Map the lifetime dependencies described in terms of the formal AST-level parameters
to the correct parameter(s) in the lowered SIL function type. There can be 0, 1,
or many SIL parameters per formal parameter because of tuple exploding. Also,
record which dependencies are on addressable parameters (meaning that the dependency
includes not only the value of the parameter, but its specific memory location).
The check is not perfect, because it only checks that the base operand is alive _at_ the mark_dependence.
Ideally it should check that the base operand is alive during the whole lifetime of the value operand.
In OSSA, the `partial_apply [on_stack]` instruction produces a value
with odd characteristics that correspond to the fact that it is lowered
to a stack-allocating instruction. Among these characteristics is the
fact that copies of such values aren't load bearing.
When visiting the lifetime-ending uses of a `partial_apply [on_stack]`
the lifetime ending uses of (transitive) copies of the partial_apply
must be considered as well. Otherwise, the borrow scope it defins may be
incorrectly short:
```
%closure = partial_apply %fn(%value) // borrows %value
%closure2 = copy_value %closure
destroy_value %closure // does _not_ end borrow of %value!
...
destroy_value %closure2 // ends borrow of %value
...
destroy_value %value
```
Furthermore, _only_ the final such destroys actually count as the real
lifetime ends. At least one client (OME) relies on
`visitOnStackLifetimeEnds` visiting at most a single lifetime end on any
path.
Rewrite the utility to use PrunedLiveness, tracking only destroys of
copies and forwards. The final destroys are the destroys on the
boundary.
rdar://142636711
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.
This was never used to generate a .swiftinterface, so can be safely removed. It
was used to guard compiler fixes that might break older .swiftinterface
files. Now, we guard the same fixes by checking the source file type.
