DIGlobalVariable had the associated expression separated into a
DIGlobalVariableExpression which ties the DIGlobalVariable and the
DIExpression together.
The original implementation of DW_OP_bit_piece was using the wrong base for the
offset. To accommodate a fix for that, the old operation was renamed. Use the
new migration name.
(cherry picked from commit 100eaf889e)
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
The original implementation of DW_OP_bit_piece was using the wrong base for the
offset. To accommodate a fix for that, the old operation was renamed. Use the
new migration name.
A pointless use of polymorphism -- the result values are not
interchangeable in any practical sense:
- For GenericTypeParamDecls, this returned getDeclaredInterfaceType(),
which is an interface type.
- For AssociatedTypeDecls, this returned the sugared AssociatedTypeType,
which desugars to an archetype.
- For TypeAliasDecls, this returned TypeAliasDecl::getAliasType(),
which desugars to a type containing archetypes.
- For NominalTypeDecls, this returned NominalTypeDecl::getDeclaredType(),
which is the unbound generic type, a special case used for inferring
generic arguments when they're not written in source.
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
This works around a compiler crash when a top-level closure is inlined
into a different compile unit. The top-level-code function is only
generated once so the parent cannot be resolved in any other CU.
This change is NFC as far as the generated DWARF is concerned.
Fixes SR-2725.
The Darwin linker won't process the debug info if the source file name
is invalid so there is no point in having a fallback implemented there.
<rdar://problem/25130236>
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
Background
----------
Now that Swift AST type support in LLDB has matured, we can stop emitting DWARF
type information by default to reduce compile time and ibject file size.
A future commit will change -g to emit only AST type references.
The full set of debug options will be
-gnone
-gline-tables-only
-g // AST types (= everything that LLDB needs)
-gdwarf-types // AST types + DWARF types (for legacy debuggers)
This saves ~4 seconds of a -r --no-assertions stdlib build and lowers
the contribution of llvm::SourceMgr::getLineAndColumn() to the total
runtime from 6% to 2%.
<rdar://problem/27016577>
This removes an assertion that no longer serves its purpose and
relaxes the IRBuilder checks for debug info when generating code
inside the debugger.
When LLDB is JIT-compiling expressions, it will not generate a
SWIFT_ENTRY_POINT_FUNCTION (there will be one per expression)
but it will still generate the equivalent of top level code.
rdar://problem/26955467
