Computing the interface type of a typealias used to push validation forward and recompute the interface type on the fly. This was fragile and inconsistent with the way interface types are computed in the rest of the decls. Separate these two notions, and plumb through explicit interface type computations with the same "computeType" idiom. This will better allow us to identify the places where we have to force an interface type computation.
Also remove access to the underlying type loc. It's now just a cache location the underlying type request will use. Push a type repr accessor to the places that need it, and push the underlying type accessor for everywhere else. Getting the structural type is still preferred for pre-validated computations.
This required the resetting of a number of places where we were - in many cases tacitly - asking the question "does the interface type exist". This enables the removal of validateDeclForNameLookup
Produce a DWO-style skeleton CU pointing to the PCH containing the
Clang debug info for types imported from a PCH. This allows
DWARFIMporterDelegate to find the type definitions there.
<rdar://problem/49233932>
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
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.
Our mangling did not encode if an Objective-C block was escaping or
not. This is not a huge problem in practice, but for debug info we
want type reconstruction to round-trip exactly. There was a previous
workaround to paper over this specific problem.
Remove the workaround, and add a new 'XL' mangling for escaping
blocks. Since we don't actually want to break ABI compatibility,
only use the new mangling in DWARF debug info.
This fixes potential LLVM verifier errors in exploded variables with undefined
elments, because a few lines below the size of fragments is derived from the
size of the LLVM SSA value and the constant used in the deleted workaround is
always an i64.
rdar://problem/51343998
A workaround in codeview debuginfo generation was to declare a condfail
instruction as inlined to avoid using 0 as an artificial line location.
However, this was done without accounting for scopes that were already
legitimately inlined. So we'd end up with a condfail inlined from
function B into function A and then the IRGen for the condfail was
being given a debugloc claiming to have been inlined again. This was
causing a sitaution where we'd have debug info forfunctionA owning an
instruction which claimed it was owned by a different function.
Fix this by first checking if the `LastScope` was already inlined and,
if so, just used that scope instead.
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
It would be nice to query the clang::SourceManager for the source
location of the clang::Decl in IRGenDebugInfo, but module out-of-date
rebuilds may unload previously loaded clang::Modules and thus also
invalidate source locations pointed to, leading to a use-after-free
here. If this functionality is desired, the source location must be
captured by ClangImporter and stored on the side.
LLDB does not actually make use of this information for non-C++ types
(it is really helpful with debugging the debug info itself, though),
so we can avoid the potential use-after-free and crash by not doing it.
<rdar://problem/48509051>
Currently LLDB calls into ide::getDeclFromMangledSymbolName() to get
to this information and we would like to get rid of this call.
rdar://problem/47798056
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
This applies the same changes from Clang CFE r349065 to the Swift
frontend to unify how filenames, cmpilation directories and absolute
paths in filenames and path remappings are handled.
