This change emits debug info for witness tables passed into generic
functions when a generic type is constrained to a protocol. This
information is required for LLDB's generic expression evaluator
to work in such functions.
rdar://104446865
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.
Improvement upon #41645 to emit the async suspend dispatch thunk's debug
info with the `linkageName` of the containing function of the async
await.
rdar://88579737
Currently IRGen requires the AST node of a variable declaration to
generate debug location. However, this will fail if the input is SIL due
to the lack of AST reconstruction. Plus, it's unnecessary since we can
just use the `SILLocation` attached on `debug_value` (and its friends) SIL
instruction to generate the correct LLVM debug metadata.
Resolves SR-14868
Usually debug info only ever describes the *result* of a projectBox
call. To display a boxed parameter of an async continuation object,
however, the debug info can only describe the box itself and thus also
needs to emit a box type for it so the debugger knows to call into
Remote Mirrors to unbox the value.
SR-14059
rdar://problem/73358988
My goal was to reduce the size of SILLocation. It now contains only of a storage union, which is basically a pointer and a bitfield containing the Kind, StorageKind and flags. By far, most locations are only single pointers to an AST node. For the few cases where more data needs to be stored, this data is allocated separately: with the SILModule's bump pointer allocator.
While working on this, I couldn't resist to do a major refactoring to simplify the code:
* removed unused stuff
* The term "DebugLoc" was used for 3 completely different things:
- for `struct SILLocation::DebugLoc` -> renamed it to `FilePosition`
- for `hasDebugLoc()`/`getDebugSourceLoc()` -> renamed it to `hasASTNodeForDebugging()`/`getSourceLocForDebugging()`
- for `class SILDebugLocation` -> kept it as it is (though, `SILScopedLocation` would be a better name, IMO)
* made SILLocation more "functional", i.e. replaced some setters with corresponding constructors
* replaced the hand-written bitfield `KindData` with C bitfields
* updated and improved comments
Previously, the name of the entry point function was always main. Here,
a new frontend flag is added to enable an arbitrary name to be
specified.
rdar://58275758
This commit depends on changes to the coroutine-splitting pass in LLVM. Shadow
copies are also turned off for async function arguments, because they make it
impossible to track debug info during coroutine splitting. Instead we are
relying on LLVM's CoroSplit.cpp to emit shadow copies. The Swift frontend gives
CoroSplit license to move do this by describing the arguments using a
dbg.declare intrinsic, even though it points to chain of load/GEP/bitcase
instructions into the Swift context function argument.
rdar://71866936
This was being done at an odd point in the frontend presumably because by that point the private discriminator had been fully computed. Instead, push the conditions for generating the prefix data down to debug info generation and stop mutating IRGenOptions::DebugFlag in the frontend.
To display a failure message in the debugger, create a function in the debug info which has the name of the failure message.
The debug location of the trap/cond_fail is then wrapped into this function and the function is declared as "inlined".
In case the debugger stops at the trap instruction, it displays the inline function, which looks like the failure message.
For example:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0000000100000cbf a.out`testit3(_:) [inlined] Unexpectedly found nil while unwrapping an Optional value at test.swift:14:11 [opt]
11
12 @inline(never)
13 func testit(_ a: Int?) -> Int {
-> 14 return a!
15 }
16
This change is currently not enabled by default, but can be enabled with the option "-Xllvm -enable-trap-debug-info".
Enabling this feature needs some changes in lldb. When the lldb part is done, this option can be removed and the feature enabled by default.
To display a failure message in the debugger, create a function in the debug info which has the name of the failure message.
The debug location of the trap/cond_fail is then wrapped into this function and the function is declared as "inlined".
In case the debugger stops at the trap instruction, it displays the inline function, which looks like the failure message.
For example:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0000000100000cbf a.out`testit3(_:) [inlined] Unexpectedly found nil while unwrapping an Optional value at test.swift:14:11 [opt]
11
12 @inline(never)
13 func testit(_ a: Int?) -> Int {
-> 14 return a!
15 }
16
This change is currently not enabled by default, but can be enabled with the option "-Xllvm -enable-trap-debug-info".
Enabling this feature needs some changes in lldb. When the lldb part is done, this option can be removed and the feature enabled by default.
Currently LLDB calls into ide::getDeclFromMangledSymbolName() to get
to this information and we would like to get rid of this call.
rdar://problem/47798056
Summary:
There are a few problems with how Swift currently emits location
information for CodeView.
1. WinDbg does not work well with column information so all column
locations must be set to zero.
2. Some instructions, e.g., ``a + b``, will emit ``@llvm.trap()``
and ``unreachable``. Those instructions should have artificial
locations, i.e., they should have a line location of zero.
3. Some instructions, e.g., ``a / b``, will emit ``unreachable``
sandwiched between other code for that instruction. This makes
WinDbg confused and it cannot decide which set of instructions
to break on. Those instructions should have the same line location
as the others.
4. There are several prologue instructions with artificial line
locations that create breaks in the linetables. Those instructions
should have valid line locations, usually at the start of the
function.
5. Case bodies have cleanup instructions with artificial line
locations unless it has a ``do`` block. Those locations should
be the last line in the case block.
Test Plan:
test/DebugInfo/basic.swift
test/DebugInfo/columns.swift
test/DebugInfo/linetable-codeview.swift
test/DebugInfo/line-directive-codeview.swift
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>
Note that this is only correct unless the variable uses inline
storage. This makes the majority of resilient types in Foundation work
as global variables. The correct solution would be for LLDB to poke
at the runtime to figure out whether the storage is inline or not, but
until then this is the next best thing.
rdar://problem/39722386
This commit changes how inline information is stored in SILDebugScope
from a tree to a linear chain of inlined call sites (similar to what
LLVM is using). This makes creating inlined SILDebugScopes slightly
more expensive, but makes lowering SILDebugScopes into LLVM metadata
much faster because entire inlined-at chains can now be cached. This
means that SIL is no longer preserve the inlining history (i.e., ((a
was inlined into b) was inlined into c) is represented the same as (a
was inlined into (b was inlined into c)), but this information was not
used by anyone.
On my late 2012 i7 iMac, this saves about 4 seconds when compiling the
RelWithDebInfo x86_64 swift standard library — or 40% of IRGen time.
rdar://problem/28311051
This fixes a crash while building the Swift standard library when
partial specializations are enabled.
Eventually we should get rid of needing the DeclContext in the mangled
typename at all, and this is one step towards that goal.
rdar://problem/31253373
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
The Darwin linker won't process the debug info if the source file name
is invalid so there is no point in having a fallback implemented there.
<rdar://problem/25130236>
