Just like in async functions, coroutines will go through the CoroSplit
flow. As such, variables in O0 need to go through the same treatment
they undergo for async functions: an `asm` directive is emitted so to
create a use of the variable after each split point.
Exit code should not inherit the location of the previous basic block;
instead, it should contain line zero to denote that this is not
associated with any user code.
Without this patch, stepping over code code like:
```
1. yielding mutate {
2. yield &member_int
3. blah
4. blah
}
```
Would go from line 3, to line 4, to line 2.
rdar://149106144
When the main IRGenSIL loop decides to use the previous instruction's
location, it does so by emitting a compiler generated location. This is
creating an issue where the return address of a borrowing accessor is
landing on such a cleanup location, making the parent frame have no line
associated with it.
Why not use the last instruction's location instead? No tests fail with
this change, and it seems to keep the literal meaning of the "use the
last location" boolean variable that already exists in code.
After https://github.com/swiftlang/swift/pull/85655, DI types for
existential typealiases and their inner protocol types are created,
which may encounter conflicts in the DIRefMap cache and assert failures
because they can have identical mangled names. This change fixes this
issue by using a separate cache for existential typealiases to avoid
such conflicts.
Issue https://github.com/swiftlang/swift/issues/86313
This is to keep clang module cache hashes consistent throughout the
build and avoid inconsistent hash errors due to the CodeGenOpts
changing at the IRGen phase in the middle of a build.
https://github.com/swiftlang/swift/issues/86116
This reverts commit b1eb70bf45.
The original PR (#85244) was reverted (#85836) due to rdar://165667449
This version fixes the aforementioned issue, and (potentially) improves overall
debug info retention by salvaging info in erase(instructionIncludingDebugUses:),
rather than inserting many explicit salvageDebugInfo calls throughout the code
to make the test cases pass.
Bridging: Make salvageDebugInfo a method of MutatingContext
This feels more consistent than making it a method of Instruction.
DebugInfo: Salvage from trivially dead instructions
This handles the case we were checking in constantFoldBuiltin, so we do not need to salvage debug info there any more.
Canonical ProtocolCompositionTypes never nest; we flatten the structure
when computing a canonical type.
However, in DWARF mangling, we might encounter ProtocolCompositionTypes
that contain other ProtocolCompositionTypes, via TypeAliasType sugar.
Make sure to visit this nested structure instead of just ignoring it.
- Fixes https://github.com/swiftlang/swift/issues/86207.
The swift compiler memsets new allocas to zero. It does this so that
LLDB is able to display a friendly 'variable is uninitialized' message
rather than garbage. Unfortunately this use of a variable before its
lifetime.start disagrees with the memtag-stack tagging pass.
This patch attaches a piece of metadata to these memsets, so that the
memtag-stack tagging pass can recognize them and work around them
appropriately.
Paired with: https://github.com/swiftlang/llvm-project/pull/11846.
rdar://162206592
Specifically, improved debug info retention in:
* tryReplaceRedundantInstructionPair,
* splitAggregateLoad,
* TempLValueElimination,
* Mem2Reg,
* ConstantFolding.
The changes to Mem2Reg allow debug info to be retained in the case tested by
self-nostorage.swift in -O builds, so we have just enabled -O in that file
instead of writing a new test for it.
We attempted to add a case to salvageDebugInfo for unchecked_enum_data, but it
caused crashes in Linux CI that we were not able to reproduce.
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
This showed up on and off again on the source-compatibility testsuite project hummingbird.
The gist of the problem is that transformations may not rewrite the
type of an inlined instance of a variable without also createing a
deep copy of the inlined function with a different name (and e.g., a
specialization suffix). Otherwise the modified inlined variable will
cause an inconsistency when later compiler passes try to create the
abstract declaration of that inlined function as there would be
conflicting declarations for that variable.
Since SILDebugScope isn't yet available in the SwiftCompilerSources
this fix just drop these variables, but it would be absolutely
possible to preserve them by using the same mechanism that SILCloner
uses to create a deep copy of the inlined function scopes.
rdar://163167975
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
This new option allows the Driver to pass the path to a compilation
job's own binary swiftmodule artifact to the frontend. The compiler
then stores this path in the debug info, to allow clients like LLDB to
unambiguously know which binary Swift module belongs to which compile
unit.
rdar://163302154
This pass removes `copy_addr` instructions.
However, it has some problems which causes compiler crashes.
It's not worth fixing these bugs because
1. Most copy_addrs can be eliminated by TempRValueElimination and TempLValueElimination.
2. Once we have opaque value we don't need copy_addr elimination, anyway.
rdar://162212460
Missed this in my previous patch, avoid relying on the `in` location
for closures with parameters and capture lists. Instead, form scopes
that start at the first element of the body. This fixes a crasher
uncovered by the fuzzer.
