In the context of coroutine/yielding accessors, "unwind" means
that the second half of the coroutine (code _after_ the `yield`
statement) will not run if an exception is thrown during the access.
Unwinding was the default behavor for legacy `_read`/`_modify` coroutine
accessors.
For the new `yielding borrow`/`yielding mutate` accessors, unwinding
was optional behind a separate feature flag.
But the final SE-0474 dictates that unwinding is always _disabled_ for
the new yielding accessors. That is, the new yielding accessors always
run to completion, regardless of whether there are thrown exceptions within
the access scope. This was deemed essential to ensure that authors of
data structures could guarantee consistency.
This PR permanently disables unwinding behavior for the new accessors.
The feature flag still exists but has no effect.
A handful of tests that verified the unwinding behavior have been
edited to ensure that unwinding does _not_ happen even when the feature
flag is specified.
Make sure an `end_borrow` is emitted on the `dereference_borrow` so that
SILGenCleanup recognizes this pattern and lowers it to a `return_borrow`
as it does for returned `load_borrow`s. Add support to the Swift implementation
of `BorrowingInstruction` for `DereferenceBorrow`.
Since after address lowering, `Borrow` can remain loadable with a known-
layout address-only referent, we need instructions that handle three
forms:
- borrow and referent are both loadable values
- borrow is a value, but referent is address-only
- borrow and referent are both address-only
Even if an indirect argument is unused, pretend that the function reads from it.
If the unused argument is passed to another generic function and that function is specialized,
the argument may be re-abstracted and the specializer inserts a load from the indirect argument.
Therefore we must be prepared that unused indirect argument might get loaded from at some time.
Fixes a compiler crash
rdar://168623362
This new OSSA invariant simplifies many optimizations because they don't have to take care of the corner case of incomplete lifetimes in dead-end blocks.
The implementation basically consists of these changes:
* add the lifetime completion utility
* add a flag in SILFunction which tells optimization that they need to run the lifetime completion utility
* let all optimizations complete lifetimes if necessary
* enable the ownership verifier to check complete lifetimes
These two new invariants eliminate corner cases which caused bugs if optimization didn't handle them.
Also, it will significantly simplify lifetime completion.
The implementation basically consists of these changes:
* add a flag in SILFunction which tells optimization if they need to take care of infinite loops
* add a utility to break infinite loops
* let all optimizations remove unreachable blocks and break infinite loops if necessary
* add verification to check the new SIL invariants
The new `breakIfniniteLoops` utility breaks infinite loops in the control flow by inserting an "artificial" loop exit to a new dead-end block with an `unreachable`.
It inserts a `cond_br` with a `builtin "infinite_loop_true_condition"`:
```
bb0:
br bb1
bb1:
br bb1 // back-end branch
```
->
```
bb0:
br bb1
bb1:
%1 = builtin "infinite_loop_true_condition"() // always true, but the compiler doesn't know
cond_br %1, bb2, bb3
bb2: // new back-end block
br bb1
bb3: // new dead-end block
unreachable
```
If a struct field is not referenced in a function and that field is not read from a called function's argument, the verifier complained that the field must be initialized.
rdar://168051370
https://github.com/swiftlang/swift/issues/86511
Introduce a new optional inferred-immutable flag on SILFunctionArgument to mark
closure-captured box parameters that are never written to despite being mutable.
This flag will enable in future commits:
- Marking captured mutable boxes as immutable when interprocedural analysis
proves they are never modified
- Treating these captures as Sendable when they contain Sendable types
- Improving region-based isolation analysis for concurrent code
This complements the inferred-immutable flag on alloc_box by allowing
immutability information to flow through closure boundaries.
"none" is like "owned" and can happen e.g. if a non-trivial enum is constructed with a trivial case:
```
%1 = enum $Optional<AnyObject>, #Optional.none!enumelt // ownership: none
...
%3 = borrowed %phi from (%1)
```
Fix a false verification error
https://github.com/swiftlang/swift/issues/86407
rdar://167833469
To help reduce cognitive burden for future Swift compiler engineers,
let's use the same terminology for coroutine accessors in SIL dumps
as we use in the surface language and inside the compiler.
This really just changes two lines in SILPrinter.cpp and updates
a lot of tests. I've also copied one test to preserve the old syntax
to make sure that SIL parsing still accepts it. That should hopefully
prevent unfortunate round-tripping issues while these changes settle.
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
`init_enum_data_addr` is a pure address projection instruction, similar to `struct_element_addr`.
It doesn't matter if the underlying memory is initialized or not at the point of this instruction.
Fixes a false memory-lifetime verification error
rdar://166962673
The MoveOnlyChecker is inserting a `destroy_addr` in a read-only access scope, which is illegal.
Relax the verification of read-only access scope by only looking at dynamic scopes.
Fixes a verifier crash.
rdar://166896665
The verifier reported a false error in case an unowned (trivial) value was used in an guaranteed phi argument outside the liverange of a borrow scope.
For example:
```
%2 = begin_borrow %0
%3 = struct_extract %2 , #KlassAndInt.int // %3 is trivial and can outlive the borrow scope
end_borrow %2
%6 = struct $KlassAndInt (%someOtherGuaranteedValue, %3)
br bb2(%6)
bb2(%8 : @guaranteed $KlassAndInt): // false error reported at the uses of %8
```
The thing with `optional<VerifierErrorEmitterGuard>` didn't work as expected.
This resulted in a null-pointer de-reference when printing a verifier error.
The diagnostic messages are not yet stabilized, so we're
getting an extra diagnostic depending on whether we're building
the stdlib in debug-asserts mode, i.e., when
```
preset=buildbot,tools=RA,stdlib=DA
```
rdar://164852821
Specifically:
1. We were tracking the stack allocation both in handleScopeInst and in the
Stack. We should only track it in one of them. I also used this as an
opportunity to make sure the code worked for non_nested code.
2. I made it so that we properly handle the end tracking part of the code so we
handle the token/stack part of begin_apply correctly. I generalized the code so
that we should handle non_nested stack allocations as well.
I included tests that validated that we now handle this correctly.
Print `forwarding: <ownership>` if the ownership of the result mismatches the operand ownership(s).
We already do this for all other forwarding instructions, but `struct` and `tuple` were missing.
With this option the ownership of instruction results is printed in the comments at the end of the line, e.g.
```
%3 = struct $S (%2, %1) // ownership: owned
```
And even without enabling this option, ownership comments are printed if the ownership of a result mismatches with its type.
That can happen e.g. for non-trivial enums which are constructed with a trivial case:
```
enum E {
case A
case B(AnyObject)
}
%1 = enum $E, #E.A!enumelt // type of %1 is non trivial, but ownership is "none"
```
We do this since we need to be able to handle instructions that may have two
different results that independently need their scopes lifetime to be ended.
This also required me to change how we handled which instruction/argument we
emit an error about in the verifier. Previously we were using two global
variables that we made nullptr to control which thing we emitted an error about.
This was unnecessary. Instead I added a little helper struct that internally
controls what we will emit an error about and an external "guard" RAII struct
that makes sure we push/pop the instruction/argument we are erroring upon
correctly.
Teach SIL type lowering to recursively track custom vs. default deinit status.
Determine whether each type recursively only has default deinitialization. This
includes any recursive deinitializers that may be invoked by releasing a
reference held by this type.
If a type only has default deinitialization, then the deinitializer cannot
have any semantically-visible side effects. It cannot write to any memory
With this patch, I'm flipping the polarity of things.
The flag `-enable-experimental-feature ManualOwnership` now turns on the diagnostics,
but they're all silenced by default. So, you need to add -Wwarning or -Werror to
your build settings to turn on the specific diagnostics you care about.
These are the diagnostic groups relevant to the feature:
- SemanticCopies aka "explicit copies mode"
- DynamicExclusivity
For example, the build setting `-Werror SemanticCopies` now gives you errors about
explicit copies, just as before, but now you can make them just warnings with -Wwarning.
To opt-out a declaration from everything when using the feature, use @_noManualOwnership.
@_manualOwnership is no longer an attribute as a result.
resolves rdar://163372569
