Since I am beginning to prepare for adding real move only types to the language,
I am renaming everything that has to do with copyable types "move only wrapped"
values instead of move only. The hope is this reduces/prevents any confusion in
between the two.
The function prologue of async funclets inherits its source location
from the hop_to_executor instruction. This makes it easier to produce
logical backtraces, since the PC in logical frames will always point
to the start if the function.
rdar://89776340
This reduces the size of the debug info of (random benchmark)
_StringProcessing.o by 1600 bytes. Modules with more arithmetic should
benefit more.
rdar://94060085
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.
