Create two versions of the following functions:
isConsumedParameter
isGuaranteedParameter
SILParameterInfo::isConsumed
SILParameterInfo::isGuaranteed
SILArgumentConvention::isOwnedConvention
SILArgumentConvention::isGuaranteedConvention
These changes will be needed when we add a new convention for
non-trivial C++ types as the functions will return different answers
depending on whether they are called for the caller or the callee. This
commit doesn't change any functionality.
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 handling of multi-basic-block control flow in `defer` blocks looks like it
was left incomplete and completely untested; I fixed a few obvious problems but
it still completely lacks any analysis of conditional reinitializations. For now,
change it to treat attempted reinitializations as uses-after-consumes so we raise
reliable errors now instead of emitting code that causes memory corruption at
runtime. Fixes rdar://129303198.
[serialized_for_package] if Package CMO is enabled. The latter kind
allows a function to be serialized even if it contains loadable types,
if Package CMO is enabled. Renamed IsSerialized_t as SerializedKind_t.
The tri-state serialization kind requires validating inlinability
depending on the serialization kinds of callee vs caller; e.g. if the
callee is [serialized_for_package], the caller must be _not_ [serialized].
Renamed `hasValidLinkageForFragileInline` as `canBeInlinedIntoCaller`
that takes in its caller's SerializedKind as an argument. Another argument
`assumeFragileCaller` is also added to ensure that the calle sites of
this function know the caller is serialized unless it's called for SIL
inlining optimization passes.
The [serialized_for_package] attribute is allowed for SIL function, global var,
v-table, and witness-table.
Resolves rdar://128406520
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.
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`.
Previously, the lexical attribute on allock_stack 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
alloc_stack 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.
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
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.
I discovered when working with improving the debug output of the move only
address checker that I had a need for lightweight thing like
DebugVarCarryingInst but that only could vend a VarDecl (unlike
DebugVarCarryingInst which also can vend a SILDebugVariable). As an example,
this lets one write a high level API that uses the standard API to loop over a
bunch of instructions all that vend a VarDecl and construct a stringified path
component list.
rdar://105293841
