Previously debug info made not difference between an existential type and a
protocol type. This caused us to loose typealiases such as
typealias Alias = ProtocolType
in the debug info.
rdar://161134092
Emit an imported declaration for @_originallyDefinedIn under the
real module that these types live in.
This patch also changes the mangling for the debugger to respect
@_originallyDefinedIn, and fixes a bug where @_originallyDefinedIn
that should be ignored was still being used when mangling.
rdar://137146961
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
Local types are not ABI, and the only time we care about the mangling here is
when we look them up using the DWARF mangling in debug info, which doesn't
respect @_originallyDefinedIn either.
Fixes https://github.com/apple/swift/issues/59773.
* Fix multi-threaded IRGen: store the DeclContext in a SILFunction explicitly instead of deriving it from the debug location. It's used in IRGen to decide into which module a function is emitted. With -gsil the debug location is changed and that should not change the module decision.
* Erase debug_value/debug_value_addr instructions when using -gsil. Those instructions are not needed anymore. They can also trigger a verifier error.
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>
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.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
When we are attempting to reconstruct a type node for a generic typealias,
make sure that we get the right number of generic arguments. If not,
fail gracefully rather than crashing.
Eventually, we should be able to handle this nested case.
This basically means the mangling isn't really quite valid, and
given we don't have a full compiler testcase to see what generates
this, we're going to reject this for now.
<rdar://problem/38931073>
This was taken from a real project, but I don't have it anymore
and I can't reproduce it on newer versions of swift (probably
something changed in the DWARF type mangling). In any case, as
this can be triggered by user input, we shouldn't assert, and
error out instead.
<rdar://problem/39283717>
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>
We were previously asserting on the following tree:
kind=Global
kind=Variable
kind=Module, text="EyeCandySwift"
kind=PrivateDeclName
kind=Identifier, text="_ADC08935D64EA4F796440E7335798735"
kind=Identifier, text="_previousUniqueNumber"
kind=Type
kind=Structure
kind=Module, text="Swift"
kind=Identifier, text="UInt64"
<rdar://problem/39283527>
This fixes the compiler side of the problem.
An lldb test will be added to make sure this doesn't regress
in the future (or, if it does, at least we know).
<rdar://problem/40261592>.
Before, we were just ignoring it, and this resulted in the type
being reconstructed incorrectly when assertion were disabled, and
in an assertion firing otherwise (AST invariants being broken).
<rdar://problem/39248252>
The mangler had a bug when mangling associated types so we got
an invalid input. Instead of ignoring the fact it's invalid,
throw an error.
Eventually we'll refactor the visitor to fail at any point in
time, as suggested by Slava, but for now, at least, stop pretending
this is a valid mangling.
Adrian reported this bug he discovered as part of his
work on improving generics in swift/lldb.
Allocators were treated as `function`, when the demangle
tree suggests they're much more akin to constructors. On
top of that, the code for handling them was commented out,
so type reconstruction was always failing. I'm not entirely
sure this is always correct, but it seems to be an improvement
on what currently type reconstruction does. At least now
we have tests so if something will break, we're going to
notice.
<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>
-enable-source-import doesn't play nice with debug info, and we want to be
able to run all tests with -g added. The last few tests that require
-enable-source-import could be built with --no-debug-info, or however we
end up spelling that.
rdar://problem/18140021 (most of it)
Swift SVN r22742
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
Previously, we were always using the first file name as the main source
file name in the debug info, which was completely wrong and led to only
that file having debug info.
<rdar://problem/15786017>, again.
Swift SVN r13665
