Not sure which LLVM commit added an `#undef` for `DEBUG_TYPE` in a header
transitively included by these files, but it doesn't seem uncommon
for headers to define and undefine their own `DEBUG_TYPE`.
Move `#define DEBUG_TYPE` after the includes to prevent it being
undefined.
This uses the previous simple dominance dbg info propagation implementation in
the previous commit.
I fix in the next commit the debug info for the last move/reinit in the var
test.
Improvement upon #41645 to emit the async suspend dispatch thunk's debug
info with the `linkageName` of the containing function of the async
await.
rdar://88579737
This fixes the issues I was in my earlier PR about seeing with vars not getting
appropriate debug info when moved. Now we get the right debug info and in the
dwarf can see the two live ranges of our moved value as we hoped for.
NOTE: I disabled alloc stack hoisting on move_function_debuginfo.swift since it
can result in us eliminating debug info at -Onone when we merge alloc_stack. I
am preparing a separate patch that fixes that issue but hit a lldb problem. This
unblocks this PR from that change since they are not /actually/ related.
Nested archetypes are represented by their base archetype kinds (primary,
opened, or opaque type) with an interface type that is a nested type,
as represented by a DependentMemberType. This provides a more uniform
representation of archetypes throughout the frontend.
`ArchetypeType` has all of the API we need for these cases, so use
that instead to isolate us from `NestedArchetypeType`, which we would
like to eliminate soon-ish.
explicit ExistentialType.
The ASTDemangler needs to produce ExistentialType based on context, not
unconditionally when producing a protocol composition. This is tricky
because existential types are mangled the same way as other protocol
references, e.g. in conformance requirements. For now, drop the explicit
existentials when reconstructing types.
by using the proper API. The old code produced the address of the hash. This
fixes a warning printed by LLDB and dsymutil about module hash mismatches and
makes the build build products more deterministic.
rdar://77344315
A PackExpansionType is the interface type of the explicit expansion of a
corresponding set of variadic generic parameters.
Pack expansions are spelled as single-element tuples with a single variadic
component in most contexts except functions where they are allowed to appear without parentheses to match normal variadic declaration syntax.
```
func expand<T...>(_ xs: T...) -> (T...)
~~~~ ~~~~~~
```
A pack expansion type comes equipped with a pattern type spelled before
the ellipses - `T` in the examples above. This pattern type is the subject
of the expansion of the pack that is tripped when its variadic generic
parameter is substituted for a `PackType`.
A pack type looks a lot like a tuple in the surface language, except there
is no way for the user to spell a pack. Pack types are created by the solver
when it encounters an apply of a variadic generic function, as in
```
func print<T...>(_ xs: T...) {}
// Creates a pack type <String, Int, String>
print("Macs say Hello in", 42, " different languages")
```
Pack types substituted into the variadic generic arguments of a
PackExpansionType "trip" the pack expansion and cause it to produce a
new pack type with the pack expansion pattern applied.
```
typealias Foo<T...> = (T?...)
Foo<Int, String, Int> // Forces expansion to (Int?, String?, Int?)
```
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
The new type, called ExistentialType, is not yet used in type resolution.
Later, existential types written with `any` will resolve to this type, and
bare protocol names will resolve to this type depending on context.
Users may want to use -fdebug-prefix-map to remap a directory to "./".
This wasn't supported previously and resulted in duplicate path
prefixes in the debug info.
With this patch swiftc behaves similar to clang when remapping a path
to a relative path.
rdar://83753143
This doesn't work for some C++ types, so, as a stop gap solution, I'm disabling it when C++ interop is enabled.
https://bugs.swift.org/browse/SR-15377 to re-enable it in the future.
This new SIL di-expression represents the dereference on the SSA value.
Similar to DW_OP_deref in DWARF. It is also going to replace the
existing `debug_value_addr`. Namely, replacing the following
instruction:
```
debug_value_addr %a : $*T, name "my_var"
```
with this one:
```
debug_value %a : $*T, name "my_var", expr op_deref
```
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
The symptom here was a crash in getConformanceAccessPath(), but the root
cause was that the ASTMangler used an incorrect generic signature when
looking up the conformance path for a type parameter.
The mangler requires a generic signature to be set to properly mangle types
containing retroactive conformances. However, DebugInfo just used the
IRGenModule's current signature, which wasn't always the same as the
signature describing the archetypes found inside the SILFunction.
Fixes rdar://problem/81683650 / https://bugs.swift.org/browse/SR-15046.
In https://reviews.llvm.org/D95617 LLVM stopped to emit debug values without a
location as an optimization for inlined functions. Because Swift is emitting
dbg.values(undef) for sizeless variables even at -Onone, we need to make sure
all local variables are preserved even at -Onone.
rdar://82038523
We were using compiler-generated source location (i.e. line number
0) on `debug_value` instructions were emitted by salvage debug info.
But it turned out that IRGen will attach DW_AT_artificial on the
associated debug variables, which are hidden in debugger by default.
This patch prevent this issue by using the source location from the
just-deleted instruction for these `debug_value` instructions.
This indirectly triggered another bug where some of the LLVM
!DIExpression-s we generated are actually invalid -- more specifically,
the fragment inside is covering the whole debug variable. The reason it was
not previously caught is because LLVM verifier skips any debug variable
that is marked artificial, and all debug variables that have illegal fragment
are falling under this category. Thus, this patch also fixes this issue
by not generating the DW_OP_LLVM_fragment part if it's illegal.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
