When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
Rather than using the `LINK_LIBRARIES` option, use target_link_libraries
like clang does. Because these are all host tools, there is no name
mangling done for the libraries making this a no-op change.
Remove the unncessary link against the DebugInfoCodeView component. THe tools
seem to build without the dependency. The dependency issue in the linkage
seems to have been resolved.
...instead of sometimes hardcoding them and sometimes using Strings.h.
The exceptions are the libraries that sit below Frontend; these can
continue using strings.
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
We want as few module passes as possible.
Function passes allow the PassManager to do its job.
e.g. it can filter certain functions that should not be applied to the
current pipeline. This will result in less work in the pass itself and
fewer pass manager related bugs.
Function passes are easier to understand and debug in the context of the
pipeline. Things like PrettyStackTrace are handled automatically.
Bisecting functionality is builtin.
Function passes are more compatible in general with inter-procedural
analysis.
Function passes are more efficient.
A single module pass in the middle of the pipeline destroys the benefit
of the rest of the pipeline uses function passes.
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
There are now separate functions for function addition and deletion instead of InvalidationKind::Function.
Also, there is a new function for witness/vtable invalidations.
rdar://problem/29311657
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
This will allow for modules to be split from the command line using a script.
The one thing that is missing from this still is that it does not handle shared
functions in IMO a satisfactory way. Given that we are splitting a module, my
feeling that the correct way to do this is to create a public shim for the
shared function in the module that the shared function gets put in and let all
other users use that entry point.
But I need to think about this a bit more.
