rdar://139106139
Regular ObjC references do not have unused bits or extra inhabitants for storing enum tags, because they may be tagged pointers. However, ObjC classes that are implemented in Swift do, so we must differentiate between the two.
In C++, a field of a derived class might be placed into the tail padding of a base class. Swift was not handling this case correctly, causing an asserts-disabled compiler to run out of RAM, and an asserts-enabled compiler to fail with an assertion.
Fixes this IRGen assertion:
```
Assertion failed: (offset >= NextOffset && "adding fields out of order"), function addField, file GenStruct.cpp, line 1509.
```
rdar://138764929
This achieves the same as clang's `-fdebug-info-for-profiling`, which
emits DWARF discriminators to aid in narrowing-down which basic block
corresponds to a particular instruction address. This is particularly
useful for sampling-based profiling.
rdar://135443278
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.
Large tuples of values (e.g char[32]) can be passed directly at the abi
boundry but expand to a big explosion of values.
Peephole this explosion at argument passing and return value passing
points to avoid code size growth associated with the explosion.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
When processing a nominal type that has the @_originallyDefinedIn attribute,
IRGenDebugInfo emits a forward declaration of the type as a child
of the original module, and the type with a specification pointing to
the forward declaration. We do this so LLDB has enough information to
both find the type in reflection metadata (the parent module name) and
find it in the swiftmodule (the module name in the type mangled name).
rdar://137146961
In GenCall, fix the IR gen for C++ method calls as under MSVC as the
calling conventions for free functions and C++ methods can be
different. This also fixes the missing inreg (on sret arguments)
issues on Windows ARM64. Also refactor to use CGFunctionInfo
returnInfo isSretAfterThis to detect when to reorder the sret and the
this arguments under MSVC.
In ClagImporter, don't drop the return type for the compound
assignment operators such as operator+= when the return value is a
reference so that the CGFunctionInfo will be correctly indicate an
indirect return for the compound assignment operators.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
As per #65930, the Clang importer's Clang instance may be configured with a different (higher) OS version than the compilation target itself in order to be able to load pre-compiled Clang modules that are aligned with the broader SDK, and match the SDK deployment target against which Swift modules are also built. Code-generation, however, must use the actual compilation target triple. This matches how Swift itself loads Swift module dependencies as well: dependency '.swiftinterface' files are type-checked against the availability epoch and code-generated against the actual compilation triple.
Resolves rdar://113712186
