Generate the full debug info for generic structs. The strategy is to
emit one full entry for the generic type with archetypes, and one
forward declaration per instantiation of the generic type.
For example, given:
```
struct Pair<T, U> {
let t: T
let u: U
}
let p1 = Pair<Int, Double>(t: 1, u: 4.2)
let p2 = Pair<String, Bool>(t: "Hello", u: true)
```
DebugInfo will have one entry for Pair<T, U> which includes descriptions
of its fields, one forward declaration of Pair<Int, Double> and one
forward declaration of Pair<String, Bool>. This information is enough
for the algorithms of RemoteMirrors to reconstruct type information for
the fully instantiated types.
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
The errorUnion type operation specifies how thrown error types are
combined when multiple errors are thrown in the same context. When
thrown error types can have type variables in them, we sometimes cannot
resolve the errorUnion until the type variables have substitutions. In
such cases, we need to persist the result of errorUnion in the
constraint solver.
Introduce the ErrorUnionType to do exactly that, and update the core
errorUnion operation to produce an ErrorUnionType when needed. At
present, this code is inert, because any errorUnion operation today
involves only concrete types. However, inference of thrown errors in
closures will introduce type variables, and depend on this.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
This patch stores the source code of macro in the source field of DIFile, which
can be used together with the DW_LLVM_LNCT_source extension to emit the source
code into DWARF debug info.
rdar://110926109
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.
This type will become the corresponding type that is resolved for an
`InverseTypeRepr`. This kind of type is not expected to appear past type
checking (currently, not even past requirement lowering!).
When building and importing modules built with
`-fmodule-file-home-is-cwd` we should be setting the debug info
directory to the current working directory. This matches the
behavior in clang: https://reviews.llvm.org/D134911
Commit 5c3ccf5050 added a number of blocks of code which were partially
removed by 39af79f491. This partial remove left lines of code doing nothin; we
remove them here.
When the function is a method, we want a DW_AT_declaration there.
Because there's no good way to cross the CU boundary to insert a nested
DISubprogram definition in one CU into a type defined in another CU when
doing LTO builds.
In C++20, `u8` literals create values of type `char8_t` instead of
`char`, and these can't be implicitly converted. This macro
mitigates the difference and allows the same code to compile under
C++14/17 modes and C++20, preserving the `char` type while ensuring
that the text is interpreted as UTF-8.
The TargetInfo pointer APIs updated to taking an "AddressSpace" type
instead of a raw integer. This goes through and updates the call
locations where this change caused build failures. In all cases, the
value passed was `0`, corresponding with the Default AddressSpace.
Adding a few more updates to places where the ABI Alignment functions
changed. `getABITypeAlignment` was replaced with `getABITypeAlign`,
which returns an `llvm::Align` instead of an unsigned int.
LLVM seems to determine a variable instance as a combination of DILocalVariable
and DILocation. Therefore if multiple llvm.dbg.declare have the same
variable/location parameters, they are considered to be referencing the same
instance of variable.
Swift IRGen emits a set of llvm.dbg.declare calls for every variable
instance (with unique SILDebugScope), so it is important that these calls have
distinct variable/location parameters. Otherwise their DIExpression may be
incorrect when treated as referencing the same variable. For example, if they
have a DIExpression with fragments, we will see this as multiple declarations of
the same fragment. LLVM detects this and crashes with assertion failure:
DwarfExpression.cpp:679: void llvm::DwarfExpression::addFragmentOffset(const
llvm::DIExpression *): Assertion `FragmentOffset >= OffsetInBits &&
"overlapping or duplicate fragments"' failed.
The patch resolves#55703. The LIT test (debug_scope_distinct.swift) is the
reproducer from that issue.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
The following tests required conflict resolutions, since upstream LLVM did a lot of
work to remove dbg.addr, and this work is not available to swift's main. At the
same time, swift's main changed these tests to enable opaque pointers.
```
both modified: test/DebugInfo/async-let-await.swift
both modified: test/DebugInfo/move_function_dbginfo.swift
both modified: test/DebugInfo/move_function_dbginfo_async.swift
```
The conflicts are fairly easy to fix: we keep the "structure" of the CHECK
lines present in `next`, but replace all pointers with `ptr`.
