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
SROA and Mem2Reg now can leverage DIExpression -- op_fragment, more
specifically -- to generate correct debug info for optimized SIL. Some
important highlights:
- The new swift::salvageDebugInfo, similar to llvm::salvageDebugInfo,
tries to restore / transfer debug info from a deleted instruction.
Currently I only implemented this for store instruction whose
destination is an alloc_stack value.
- Since we now have source-variable-specific SIL location inside a
`debug_value` instruction (and its friends), this patch teaches
SILCloner and SILInliner to remap the debug scope there in addition
to debug scope of the instruction.
- DCE now does not remove `debug_value` instruction whose associating
with a function argument SSA value that is not used elsewhere. Since
that SSA value will not disappear so we should keep the debug info.
This patch is primarily doing two things:
- Teach IRGen for some of the instructions to generate debug info based
on SILDebugVariable rather than AST node, which is not always
available when reading from SIL.
- Generate corresponding `llvm.dbg.*` intrinsics and `!DIExpression`
from the newly added SIL DIExpression.
Remove the default argument for the `memberType`
parameter and enforce that GenericFunctionType is
not passed. Also add a defaulted overload for the
property case, as they should never have a
GenericFunctionType interface type.
Currently IRGen requires the AST node of a variable declaration to
generate debug location. However, this will fail if the input is SIL due
to the lack of AST reconstruction. Plus, it's unnecessary since we can
just use the `SILLocation` attached on `debug_value` (and its friends) SIL
instruction to generate the correct LLVM debug metadata.
Resolves SR-14868
IRGen tried to decode various types of `SILLocation` into
`FilenameAndLocation` object. But it couldn't handle the case where
`SILLocation` already uses `FilenameAndLocationKind` storage kind. This
patch fixes this issue.
Resolves SR-14856
This patch removes a heuristic to promote all debug intrinsics pointing into
allocas to llvm.dbg.declare() intrinsics and instead more accurate classifies
variables in async contexts by adding the missing cases alloc_box and
alloc_stack cases.
rdar://78977132
DebugInfoTypes didn't properly distinguish between types with an unknown size
and used 0 as the default value. This can cause types to show up in DWARF with a
size of 0, which will prevent LLDB from looking at the type further. In
practice, this meant that many resilient types (for example, SwiftUI Views)
couldn't be displayed in the debugger and just showed up as empty.
This patch does three things:
0. Make size in DebugTypeInfo optional.
1. Introduce CompletedDebugTypeInfo, a subclass of DebugTypeInfo where
size is guaranteed to be non-empty.
2. Change some APIs that only make sense with a size to use
CompletedDebugTypeInfo. This caused some churn because I needed to refactor
the get*Elements() functions back into their callers to facilitate the new
early-exit path. These functions are only called when compiling with
-gdwarf-types.
3. Change createOpaqueStructWithSizedContainer() to create a size-less forward
declaration instead of a zero-sized type for the inner type.
rdar://76973844
(cherry picked from commit b8e6eebdbc)
