Updates ConsumeOperatorCopyableValuesChecker to identify store_borrow
instructions as a liveness-affecting use so that patterns that would
previously slip through undiagnosed are correctly identified. e.g.
```swift
func use<V>(_ v: borrowing V) {}
func f() {
let a = A()
_ = consume a
use(a) // previously would not be diagnosed
}
```
This is necessary to fix a recent OSSA bug that breaks common occurrences on
mark_dependence [nonescaping]. Rather than reverting that change above, we make
forward progress toward implicit borrows scopes, as was the original intention.
In the near future, all InteriorPointer instructions will create an implicit
borrow scope. This means we have the option of not emitting extraneous
begin/end_borrow instructions around intructions like ref_element_addr,
open_existential, and project_box. After that, we can also migrate
GuaranteedForwarding instructions like tuple_extract and struct_extract.
In preparation for only recording the defs once, replace the
GraphNodeWorklist of defs with a SetVector. Preserve the current
visitation order by creating a worklist of indices to be visited.
When checking whether an instruction is contained in a liveness
boundary, a pointer to a DeadEndBlocks instance must always be passed.
When the pointer is null, it is only checked that the instruction occurs
within the direct live region. When the pointer is non-null, it is
checked whether the instruction occurs within the region obtained by
extending the live region up to the availability boundary within
dead-end regions that are adjacent to the non-lifetime-ending portion of
the liveness boundary.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
The checker already verifies that no non-destroy consuming users occur
after any `move_value`s corresponding to `consume` operators applied to
a value. There may, however, be _destroy_ users after it.
Previously, the checker did not shorten the lifetime from those destroys
up to `move_value`s that appear after those `move_value`s. The result
was that the value's lifetime didn't end at the `consume`.
Here, the checker is fixed to rewrite the lifetimes so that they both
end at `consume`s and also maintain their lexical lifetimes on paths
away from the `consume`s. This is done by using
`OwnedValueCanonicalization`/`CanonicalizeOSSALifetime`.
Specifically, it passes the `move_value`s that correspond to
source-level `consume`s as the `lexicalLifetimeEnds` to the
canonicalizer. Typically, the canonicalizer retracts the lexical
lifetime of the value from its destroys. When these `move_value`s are
specified, however, instead it retracts them from the lifetime boundary
obtained by maximizing the lifetime within its original lifetime while
maintaining the property that the lifetime ends at those `move_value`s.
rdar://113142446
Emitting a note with an invalid source location is actively
harmful. It confuses users and tools, makes it impossible to write
unit tests. In this case, the note simply says "use here", so it's
completely free of information without the source location.
This fixes bugs when ~Escapable types depended on values that are passed to 'consume'.
The consume operator diagnostics are broken when dependent values are
present. This sidesteps the problem for lifetime dependence. And we
generally want to diagnose lifetime dependence after all move-only
related diagnostics. That way, using a dependent value after consume
provides a more informative diagnostic about the dependent value and
its scope.
Such values could be referenced in a ConsumeExpr, so the checker must
check them. Furthermore, it's legal to consume such values so long as
they aren't annotated `borrowing`.
For years, optimizer engineers have been hitting a common bug caused by passes
assuming all SILValues have a parent function only to be surprised by SILUndef.
Generally we see SILUndef not that often so we see this come up later in
testing. This patch eliminates that problem by making SILUndef uniqued at the
function level instead of the module level. This ensures that it makes sense for
SILUndef to have a parent function, eliminating this possibility since we can
define an API to get its parent function.
rdar://123484595
Now that SILGen almost always represents a lexical lifetime with
move_value [lexical]
the fact that the checker doesn't consider such lifetimes is exposed.
Fix it to look for such lifetimes.
Previously, the lexical attribute on begin_borrow instructions was used.
This doesn't work for values without lexical lifetimes which are
consumed, e.g. stdlib CoW types. Here, the new var_decl attribute on
begin_borrow is keyed off of instead. This flag encodes exactly that a
value corresponds to a source-level VarDecl, which is the condition
under which checking needs to run.
rdar://118059326
Specifically, we previously emitted a "compiler doesn't understand error", so we
were always emitting an error appropriately. This just gives a better error
message saying instead that the compiler did understand what happened and that
one cannot apply consume to globals or escaping captures.
https://github.com/apple/swift/issues/67755
rdar://112561671
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
