Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
By populating the memory cache before loading the module, we can avoid a cycle
where a module is imported that is an overlay, which then triggers
ClangImporter, which then (redundantly) triggers the import of the overlay
module, which would reimport the module again, since it's import is still
underway and it hasn't been entered into the cache yet.
rdar://118846313
A swiftmodule can only be correctly ingested by a compiler
that has a matching state of using or not-using
NoncopyableGenerics.
The reason for this is fundamental: the absence of a Copyable
conformance in the swiftmodule indicates that a type is
noncopyable. Thus, if a compiler with NoncopyableGenerics
reads a swiftmodule that was not compiled with that feature,
it will think every type in that module is noncopyable.
Similarly, if a compiler with NoncopyableGenerics produces a
swiftmodule, there will be Copyable requirements on each
generic parameter that the compiler without the feature will
become confused about.
The solution here is to trigger a module mismatch, so that
the compiler re-generates the swiftmodule file using the
swiftinterface, which has been kept compatible with the compiler
regardless of whether the feature is enabled.
This reverts commit 3cc2831608.
The compiler's revision check has been relaxed since the feature was introduced
and so it's nos better to reduce the number of special code paths for LLDB in
the compiler to facilitate reasoning about it.
rdar://117824367
On macOS it is possible for one application to contain Swift modules compiled
for different triples that are incompatible as far as the Swift compiler is
concerned. Examples include an iOS simulator application hunning on a macOS
host, or a macCatalyst application running on macOS. A debugger might see
.swift_ast sections for all triples at the same time. This patch adds an
interface to let the client provide a triple to filter Swift modules in an
ASTSection.
rdar://107869141
For release-management purposes during development, LLDB's embedded Swift
compiler's version number can sometimes be off-by-one in the last digit
compared to the Swift compiler.
This patch restores the old behavior from before 17183629e4.
rdar://101299168
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
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.
All of these are tools that are only meant to be used when testing swift. Thus
it doesn't make sense to include them in the catch all 'tools' install component
that distributions use to build all the tools.
I verified that all of the mac/linux presets in tree that have tools also has
testsuite-tools so this should be NFC. On Windows, I needed to add
testsuite-tools to build-windows.bat so should be NFC there as well.
* 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
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
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
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.
