Fix new clang warnings that can indicate potential use-after-free from
dangling pointers.
The issues are mostly coming from `llvm::function_ref` are not owning
the function, and `std::function` should be used in those cases.
This instruction converts Builtin.ImplicitActor to Optional<any Actor>. In the
process of doing so, it masks out the bits we may have stolen from the witness
table pointer of Builtin.ImplicitActor. The bits that we mask out are the bottom
two bits of the top nibble of the TBI space on platforms that support TBI (that
is bit 60,61 on arm64). On platforms that do not support TBI, we just use the
bottom two tagged pointer bits (0,1).
By using an instruction, we avoid having to represent the bitmasking that we are
performing at the SIL level and can instead just make the emission of the
bitmasking an IRGen detail. It also allows us to move detection if we are
compiling for AArch64 to be an IRGen flag instead of a LangOpts flag.
The instruction is a guaranteed forwarding instruction since we want to treat
its result as a borrowed projection from the Builtin.ImplicitActor.
* When constructing instructions which have substitution maps: initialize those with the canonical SubstitutionMap
* Also initialize SILFunction::ForwardingSubMap with the canonical one
Non-canonical substitution maps may prevent generic specializations.
This fixes a problem in Embedded Swift where an error is given because a function cannot be specialized, although it should.
https://github.com/swiftlang/swift/issues/83895
rdar://159065157
The SIL optimizer has fundamental bugs that result in dropping non-Copyable
struct & enum the deinitializers.
Fix this by
1. correctly representing the ownership of struct & enum values that are
initialized from trivial values.
2. checking move-only types before deleting forwarding instructions.
These bugs block other bug fixes. They are exposed by other unrelated SIL
optimizations to SIL. I'm sure its possible to expose the bugs with source-level
tests, but the current order of inlining and deinit devirtualization has been
hiding the bugs and complicates reproduction.
We are going to need to add more flags to the various checked cast
instructions. Generalize the CastingIsolatedConformances bit in all of
these SIL instructions to an "options" struct that's easier to extend.
Precursor to rdar://152335805.
When performing a dynamic cast to an existential type that satisfies
(Metatype)Sendable, it is unsafe to allow isolated conformances of any
kind to satisfy protocol requirements for the existential. Identify
these cases and mark the corresponding cast instructions with a new flag,
`[prohibit_isolated_conformances]` that will be used to indicate to the
runtime that isolated conformances need to be rejected.
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.
A begin_apply token may be used by operands that do not end the coroutine:
mark_dependence.
We need an API that gives us only the coroutine-ending uses. This blocks
~Escapable accessors.
end_borrow is considered coroutine-ending even though it does not actually
terminate the coroutine.
We cannot simply ask isLifetimeEnding, because end_apply and abort_apply do not
end any lifetime.
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.
Collect all types in the substitution map which constitute
type-dependent operands and record them in the instruction's operand
list. Fixes a bug where open_existential_metatype (e.g.) is deleted as
dead because it has no users even when the type it defines is used in a
substitution map of a builtin.
When its operand has coroutine kind `yield_once_2`, a `begin_apply`
instruction produces an additional value representing the storage
allocated by the callee. This storage must be deallocated by a
`dealloc_stack` on every path out of the function. Like any other stack
allocation, it must obey stack discipline.
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
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)
getVarInfo() now always returns a variable with a location and scope.
To opt out of this change, getVarInfo(false) returns an incomplete variable.
This can be used to work around bugs, but should only really be used for
printing.
The complete var info will also contain the type, except for debug_values,
as its type depends on another instruction, which may be inconsistent if
called mid-pass.
All locations in debug variables are now also stripped of flags, to avoid
issues when comparing or hashing debug variables.
When a store is salvaged, its debug_value will have two locations:
the location of the store, attached to the debug_value instruction,
and the location of the variable, attached to the SILDebugVariable.
The getDecl function was using the location of the store, instead
of the location of the variable, and so was returning nullptr.
