Currently the Swift compiler makes these instructions with SILLocations marked
as autgenerated. While this allows for somewhat smoother stepping in some cases,
it can also make some debugging tasks harder due to missing source location
information, for example, when attributing memory allocations.
This patch makes these locations available again, based on that a debug info
consumer could consider filtering them out by recognizing that a source location
is on the opening `{` of a closure, but inside the scope of the function the
closure is defined in.
rdar://127095833
The mangled name produced for the debugger should match the one emitted
in reflection metadata, otherwise LLDB will not be able to lookup types
when the module is compiled with the -module-abi-name flag.
rdar://125848324
Salvage Debug Info was only being called for simplifications, and not
for function passes written in Swift. Salvage Debug Info is now called
for both cases.
The source location for the variable should be the value in VarInfo if set,
otherwise it should use the location of the instruction. Both ways should
be consistent, and as we use column number if VarInfo is set, we have to do
it if isnt, too.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
This fixes an issue where the debug locations for Swift traps were dropped in the produced PDB files, as they were pointing to line 0
I validated this on a sample project using WinDbgx, which can now correctly trap on the same line in multiple places
Specialized types are generic types, or types whose parent is
specialized.
IRGenDebugInfo was previously mistankenly emitting debug info for
nominal specialized types as if they regular nominal types, which caused
problems as that code path does not handle references to generic
parameters.
Previously, the lexical attribute on allock_stack instructions was used.
This doesn't work for values without lexical lifetimes which are
consumed, e.g. stdlib CoW types. Here, the new var_decl attribute on
alloc_stack is keyed off of instead. This flag encodes exactly that a
value corresponds to a source-level VarDecl, which is the condition
under which checking needs to run.
In the end this condition exists to avoid a BitCode Verifyer check that operates
off the scope, so looking for that directly is more future-proof.
rdar://123334375
To properly initialize the compiler instance on LLDB when debugging
embedded Swift programs, emit "-enable-embedded-swift" into the
DW_AT_APPLE_flags attribute of the compile unit.
When emitting a method definition in debug info, the compiler should
also emit the method's declaration, because LLVM LTO can't unify type
definitions when a child DIE is a full subprogram definition. This is
already the behavior for standard methods, this patch implements the
same behavior for witness and objc methods as well.
rdar://123334375
When generating full debug info for generic types, emit the
specification type as an opaque struct with the collection of
substituted generic parameters.
The instructions related to producing DynamicSelf metadata are always placed at
the start of the function. This creates an issue: which debug location should be
used in order to preserve a sane line table? The current implementation just
uses w/e debug location is present in the new insertion point, which could, for
example, be a debug_declare whose location is not suitable for these purposes.
This patch addresses the issue by removing the debug location of instructions
associated with producing DynamicSelfMetadata.
rdar://120408665
