This commit also changes how specialized types are being emitted. Previously we
would not emitthe detailed member information in the specialized type itself,
and instead rely on the fact that it was present in the unspecialized type,
however, this wold prevent us from emitting any bound generic members, so we're
now emitting the members in both variants of the type.
This uncovered a with type aliases that this commit also addresses: Because we
don't canonicalize types prior to caching in order to preserve type sugar,
alternative representations of recursive types (with one or more levels of
recursion unfolded) could create potential infinite chains of types. This is
addressed by checking whether a sugared type has an already emitted canonical
representation first, and if yes, creating a typedef node pointing directly to
it.
The donwside of doing this is that it can lead to the disappearnce of type
aliases definitions when they are used as parameters in bound generic
types. However, we still preserve that a type was `MyClass<MyAlias>`. We just
might have a typedef pointing director from `MyClass<MyAlias>` ->
`MyClass<CanonicalType>`.
rdar://144315592
Replace the generation of debug info for enums from DW_TAG_union_type
to either DW_TAG_enumeration_type or DW_TAG_variant_part, as these
representation match Swift enums more closely.
Previously type sizes would be inconsistently sourced from either the LLVM type
or the FixedTypeInfo, depending on the call site. This was problematic because
TypeInfo operates with a resolution of whole bytes, which means that types such
as i1 would get a reported as having a size of 8. This patch now asserts that
all occurrences of the same type have the same size as the first, cached
occurence.
To avoid triggering the cached type verification assertion, this patch avoids
caching of storage-sized containers. It also removes the unique identifier from
forward declarations, which could lead to type confusion during LTO.
rdar://102367872
DebugInfoTypes didn't properly distinguish between types with an unknown size
and used 0 as the default value. This can cause types to show up in DWARF with a
size of 0, which will prevent LLDB from looking at the type further. In
practice, this meant that many resilient types (for example, SwiftUI Views)
couldn't be displayed in the debugger and just showed up as empty.
This patch does three things:
0. Make size in DebugTypeInfo optional.
1. Introduce CompletedDebugTypeInfo, a subclass of DebugTypeInfo where
size is guaranteed to be non-empty.
2. Change some APIs that only make sense with a size to use
CompletedDebugTypeInfo. This caused some churn because I needed to refactor
the get*Elements() functions back into their callers to facilitate the new
early-exit path. These functions are only called when compiling with
-gdwarf-types.
3. Change createOpaqueStructWithSizedContainer() to create a size-less forward
declaration instead of a zero-sized type for the inner type.
rdar://76973844
(cherry picked from commit b8e6eebdbc)
These line numbers are consumed by LLDB and stored in the Declaration object,
but as far as I can tell no user-facing feature relies on this.
Removing the line number can reduce the churn for incremental builds
significantly, since whitespace changes in one file may trigger a recompilation
of any file that uses a type declared below the whitespace change.
<rdar://problem/63156560>
This is needed to anchor any typedefs that appear in bound generic parameters so
they can be resolved in the typeref-based part of the debugger without needing
to query the Swift module.
This patch changes the DWARF representation of bound generic enums to a nested
struct where the (sized) outer struct is anonymous and thus distinct and the
inner struct in uniqued and sizeless.
BoundGenericEnums may have different sizes depending on what they are bound to,
but still share a mangled name.
rdar://problem/56521648
instead of using name and decl context.
The advantages of this approach are three-fold:
- This is necessary to support inlined generic functions.
- We can retire the debugger-specific type name manfgling mode for archetypes.
- This saves 270kb of debug information in the x86_64 libSwiftCore.dylib alone.
<rdar://problem/38306256>
This patch emits the alignment for all default-aligned types as 0
which causes the backend to not emit an alignment attribute at
all. This mirrors clang's behavior.
<rdar://problem/29007471>
Value witness tables have a well-known symbol name, so there is nothing
that the debug info adds on top of it.
On top of that, the DWARF type we previously were emitting them with was
bogus.
rdar://problem/21777112
Now that we open-code enum construction, enum constructor entry points are
only needed when they are partially-applied, which is a rare case. So we
treat them like curry thunks and only emit them as needed.
The main consequence of this is that enum case constructors are no longer
part of our ABI.
To avoid a regression in the code path for diagnosing infinite value types,
force type lowering to walk a type when emitting its declaration, even if
there are no other references to the type in the program (which is now the
case for public enums which are otherwise not used).
Also XFAIL a DebugInfo test since it is not clear to me what the test does
or how to fix it. The obvious change of adding references to the enum
case constructor function to force it to be emitted did not work.
And include some supplementary mangling changes:
- Give the first generic param (depth=0, index=0) a single character mangling. Even after removing the self type from method declaration types, 'Self' still shows up very frequently in protocol requirement signatures.
- Fix the mangling of generic parameter counts to elide the count when there's only one parameter at the starting depth of the mangling.
Together these carve another 154KB out of a debug standard library. There's some awkwardness in demangled strings that I'll clean up in subsequent commits; since decl types now only mangle the number of generic params at their own depth, it's context-dependent what depths those represent, which we get wrong now. Currying markers are also wrong, but since free function currying is going away, we can mangle the partial application thunks in different ways.
Swift SVN r32896
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
When computing the locations for local indirect enums, we could enter
an infinite loop if the first field is a recursive reference.
Just bail out of the field-splitting logic if we encounter an indirect
case. More work might be needed if indirect enums get exploded.
rdar://problem/21927941
Swift SVN r30717
create a replaceable forward declaration while building it.
This fixes a crash when building generic enums a tuple element recursively
referenceing the enum.
rdar://problem/21326786
Swift SVN r29416
and create a replaceable forward declaration while building it.
This fixes a crash when building generic enums with a constructor
function.
<rdar://problem/21294835>
Swift SVN r29411
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
