See https://github.com/llvm/llvm-project/pull/161403.
These `isa` calls with a `CanType` no longer compile with LLVM next
because the implementation now unfolds directly to `CastInfo` calls
rather than non-variadic `isa` calls that resolve to our partial
specializations here:
e293876e4f/include/swift/AST/Type.h (L600)
We should partially specialize `CastInfo` instead of `isa` et al. For
now, just use the non-variadic `isa`.
The underlying C++ code expects a non-null `Instruction*` or `SILArgument*` pointer, and
most of the contextual information in a verifier error is derived from these arguments,
so it doesn't really make sense for the Swift level interface to present these arguments
as optional.
This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
We first have to remove _all_ old entries from the cache, then add the new entries.
Otherwise we'll wrongly remove an existing entry from the cache again if a previous entry was deleted from the vtable.
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.
else-if chains provide the possibility that there is additional code after the
else-if chain. In this case, no such code exists, so by using early continues we
communicate that the iteration ends at the end of an if block and the programmer
does not need to read to the end of the else-if block.
This also allows for me to eliminate one level of indentation in the successor
code as well.
This has grown large enough and complex enough that it makes sense to go into
its own file.
This is a NFCI change. The only substantial changes is I added a small require
impl based on the one in SILVerifier and I eliminated the namespace
VerifyFlowSensitiveRulesDetails.
This ensures that a `borrow` accessor doesn't introduce temporary bitwise copies of the
representation that could foreshorten the lifetime of memory-dependent references.
Embedded Swift ends up rewriting the linkage of global variables as
part of linking together all of the Swift modules. Doing so for extern
global variables (e.g., ones meant to be implemented in C) breaks the
LLVM module, because they will never have definitions. Only make this
change when the global variable is a definition.
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.
This function will give the wrong convention in SILGen when
using -enable-sil-opaque-values. In particular, it will say
arguments are indirect when they are not.
The `shouldExpand` in `OptUtils.swift` was incorrectly returning `true`
unconditionally when `useAggressiveReg2MemForCodeSize` was disabled. The
expansion might be invalid for types with addr-only types and structs
with deinit, but we didn't check them before. This could lead to invalid
`destructure_struct` instructions without `drop_deinit` being emitted.
This eliminates a SIL verification error with `@c` functions, which
provide definitions for foreign entrypoints. We were serializing @c
definitions when we shouldn't be, which would cause problems down the
line if those @c definitions referenced something internal that they
shouldn't.
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 multi-threaded IRGen, the global variables associated with "once"
initialization tokens were not getting colocated with their actual
global variables, which caused the initialization code to get split
across different files. This issue manifest as autolinking errors in
some projects.
Fixes rdar://162400654.
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
This showed up on and off again on the source-compatibility testsuite project hummingbird.
The gist of the problem is that transformations may not rewrite the
type of an inlined instance of a variable without also createing a
deep copy of the inlined function with a different name (and e.g., a
specialization suffix). Otherwise the modified inlined variable will
cause an inconsistency when later compiler passes try to create the
abstract declaration of that inlined function as there would be
conflicting declarations for that variable.
Since SILDebugScope isn't yet available in the SwiftCompilerSources
this fix just drop these variables, but it would be absolutely
possible to preserve them by using the same mechanism that SILCloner
uses to create a deep copy of the inlined function scopes.
rdar://163167975
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
