Instead of checking that the stdlib can be loaded in a variety of places, check it when setting up the compiler instance. This required a couple more checks to avoid loading the stdlib in cases where it’s not needed.
To be able to differentiate stdlib loading failures from other setup errors, make `CompilerInstance::setup` return an error message on failure via an inout parameter. Consume that error on the call side, replacing a previous, more generic error message, adding error handling where appropriate or ignoring the error message, depending on the context.
* Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag
This includes a bit in the module format to represent if the module was
compiled with -enable-ossa-modules flag. When compiling a client module
with -enable-ossa-modules flag, all dependent modules are checked for this bit,
if not on, recompilation is triggered with -enable-ossa-modules.
* Updated tests
This part of a series of patches to bring ASTPrinter and Swift Demangler to
feature parity, which is needed by LLDB, which depends on using the strings
produced by either interchangibly.
rdar://problem/63700540
LLVM svn r368826 changed the SectionRef::getName() interface to return an
Expected<StringRef> instead of filling out one that is passed to it.
Adjust accordingly.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.
Updated uses of object::SectionRef::getContents() since it now returns
an Expected<StringRef> instead of modifying the one it's passed.
See also: git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@360892
91177308-0d34-0410-b5e6-96231b3b80d8
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
lldb-moduleimport-test would only check for MachO and ELF object file
formats. However, Windows uses COFF object files. Add that to the list
of formats that we check. This allows us to inspect content built for
Windows.
There was only one remaining usage other than in testing tools.
Note that when a declaration mangling was passed in, the old entry
point would (try to) return the type of the declaration.
The new entry point no longer has this behavior. I changed the
bridging-header-first test to run lldb-moduleimport-test with
-decl-from-mangled instead of -type-from-mangled-old to preserve
the behavior of the test.
Also, I removed test/DebugInfo/DumpTypeFromMangledName.swift
completely. This test only covered a handful of cases, and a bunch
of them were declaration manglings rather than type manglings.
The new tests in test/TypeDecoder/ are much more comprehensive.
The -type-from-mangled flag now uses the new API. The -type-from-mangled-old flag
uses the old API, ide::getTypeFromMangledSymbolname().
For now, just change all existing tests to use the -type-from-mangled-old flag;
I'll be adding new tests for the new API shortly.
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
LLDB needs the -swift-version because the -D__swift__ macro affects
how Clang modules are built. This currently has the really odd effect
that when debugging a Swift program that is not using the very latest
Swift version, the first "po" takes several seconds, because the
module cache needs to be rebuilt.
rdar://problem/40241256
This is in preparation for fetching informations directly from
the module instead of specifying them on the cmdline. It will
serve us better as it will mimick more accurately the way lldb
is behaving.
This refactoring moves the validation of the modules earlier
so that we can use the validation info to create the CompileUnit.
<rdar://problem/38867076>
We're going to infer all these informations from the module, but
that's a large refactoring task which I'm going to do next.
In the meanwhile, this should allow Adrian's work to be unblocked.
<rdar://problem/38720742>
Adrian already found and reported a bug, which I'm going to fix
in a later commit. Eventually this will go away, but in the meanwhile,
we should add test for this codepath.
<rdar://problem/38720742>
The only way we had to test this path was through swift-ide-test,
which takes an input a source file, instead of a serialized module.
This is not the scenario that lldb tests, hence this patch.
<rdar://problem/38323564>
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.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
...with a better message than the generic "older version of the
compiler" one, when we know it's actually a different version of
Swift proper.
This still uses the same internal module version numbers to check
if the module is compatible; the presentation of language versions
is a diagnostic thing only.
Speaking of module version numbers, this deliberately does NOT
increment VERSION_MINOR; it's implemented in a backwards-compatible
way.
This will only work going forwards, of course; all existing modules
don't have a short version string, and I don't feel comfortable
assuming all older modules we might encounter are "Swift 2.2".
rdar://problem/25680392
I also added a macro called INITIALIZE_LLVM(argc, argv) which moves this logic
into one place and should be used at the beginning of *all* binaries. It
initializes an LLVM shutdown object, sets up the pretty stack trace, and then
initializes all of the parts of LLVM. This will make it easy to update this in
the future.
The reason why a macro was required was because of llvm_shutdown_obj, an RAII
object that cleans up LLVM. It has to be at the function level scope of the main
function.
Swift SVN r31815
