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)
Usually debug info only ever describes the *result* of a projectBox
call. To display a boxed parameter of an async continuation object,
however, the debug info can only describe the box itself and thus also
needs to emit a box type for it so the debugger knows to call into
Remote Mirrors to unbox the value.
SR-14059
rdar://problem/73358988
My goal was to reduce the size of SILLocation. It now contains only of a storage union, which is basically a pointer and a bitfield containing the Kind, StorageKind and flags. By far, most locations are only single pointers to an AST node. For the few cases where more data needs to be stored, this data is allocated separately: with the SILModule's bump pointer allocator.
While working on this, I couldn't resist to do a major refactoring to simplify the code:
* removed unused stuff
* The term "DebugLoc" was used for 3 completely different things:
- for `struct SILLocation::DebugLoc` -> renamed it to `FilePosition`
- for `hasDebugLoc()`/`getDebugSourceLoc()` -> renamed it to `hasASTNodeForDebugging()`/`getSourceLocForDebugging()`
- for `class SILDebugLocation` -> kept it as it is (though, `SILScopedLocation` would be a better name, IMO)
* made SILLocation more "functional", i.e. replaced some setters with corresponding constructors
* replaced the hand-written bitfield `KindData` with C bitfields
* updated and improved comments
Previously, the name of the entry point function was always main. Here,
a new frontend flag is added to enable an arbitrary name to be
specified.
rdar://58275758
The generic signature isn't used for a whole lot, so this all mostly
worked before; the test case I have hits the code path for mangling
a retroactive conformance.
Fixes <https://bugs.swift.org/browse/SR-14016> / <rdar://problem/72865083>.
Since these types have an implicit stored property, this requires
adding an abstraction over fields to IRGen, at least throughout
the class code. In some ways I think this significantly improves
the code, especially in how we approach missing members.
Fixes rdar://72202671.
This commit depends on changes to the coroutine-splitting pass in LLVM. Shadow
copies are also turned off for async function arguments, because they make it
impossible to track debug info during coroutine splitting. Instead we are
relying on LLVM's CoroSplit.cpp to emit shadow copies. The Swift frontend gives
CoroSplit license to move do this by describing the arguments using a
dbg.declare intrinsic, even though it points to chain of load/GEP/bitcase
instructions into the Swift context function argument.
rdar://71866936
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
This patch includes a large number of changes to make sure that:
1. When ExtInfo values are created, we store a ClangTypeInfo if applicable.
2. We reduce dependence on storing SIL representations in ASTExtInfo values.
3. Reduce places where we sloppily create ASTExtInfo values which should
store a Clang type but don't. In certain places, this is unavoidable;
see [NOTE: ExtInfo-Clang-type-invariant].
Ideally, we would check that the appropriate SILExtInfo does always store
a ClangTypeInfo. However, the presence of the HasClangFunctionTypes option
means that we would need to condition that assertion based on a dynamic check.
Plumbing the setting down to SILExtInfoBuilder's checkInvariants would be too
much work. So we weaken the check for now; we should strengthen it once we
"turn on" HasClangFunctionTypes and remove the dynamic feature switch.
To avoid ambiguity, ImportResolution and a few other things used the term “decl path” instead of “access path”. Switch back to the correct terminology now that the compiler is becoming more consistent about it.
Instead of using `UnresolvedType` as a placeholder for a type hole,
let's switch over to a dedicated "rich" `HoleType` which is capable
of storing "originator" type - type variable or dependent member
type which couldn't be resolved.
This makes it easier for the solver to determine origins of
a hole which helps to diagnose certain problems better. It also
helps code completion to locate "expected type" of the context
even when it couldn't be completely resolved.
When we try to emit debug info from C++ types we crash because we can't deserialize them. This is a temporary fix to circumnavigate the crash before a real fix can be created.
