This patch re-enables the compat library on a couple of tests. The issue
was that the compat library was pulling in compiler-rt symbols for
determining system version. That was fixed with a little dlsym action in
188c7bd626. It was using the symbols to
determine if we had voucher_needs_adopt. It just took a while to
re-enable it in these tests.
The old behavior was only correct when building substituted types,
ie, if createTupleType() was never called with a pack expansion type.
This was the case in the runtime's MetadataLookup which applies
substitutions to an interface type to ultimately construct metadata
for a fully-concrete type, but not in the ASTDemangler, where we
actually build interface types.
Since TypeDecoder doesn't have any way to query the kind of type
it just built, let's just instead make this decision inside the
implementation of the type builder concept.
Fixes https://github.com/apple/swift/issues/67322.
This attribute can be attached to a noncopyable struct to specify that its
storage is raw, meaning the type definition is (with some limitations)
able to do as it pleases with the storage. This provides a basis for
implementing types for things like atomics, locks, and data structures
that use inline storage to store conditionally-initialized values.
The example in `test/Prototypes/UnfairLock.swift` demonstrates the use
of a raw layout type to wrap Darwin's `os_unfair_lock` APIs, allowing
a lock value to be stored inside of classes or other types without
needing a separate allocation, and using the borrow model to enforce
safe access to lock-guarded storage.
LLVM seems to determine a variable instance as a combination of DILocalVariable
and DILocation. Therefore if multiple llvm.dbg.declare have the same
variable/location parameters, they are considered to be referencing the same
instance of variable.
Swift IRGen emits a set of llvm.dbg.declare calls for every variable
instance (with unique SILDebugScope), so it is important that these calls have
distinct variable/location parameters. Otherwise their DIExpression may be
incorrect when treated as referencing the same variable. For example, if they
have a DIExpression with fragments, we will see this as multiple declarations of
the same fragment. LLVM detects this and crashes with assertion failure:
DwarfExpression.cpp:679: void llvm::DwarfExpression::addFragmentOffset(const
llvm::DIExpression *): Assertion `FragmentOffset >= OffsetInBits &&
"overlapping or duplicate fragments"' failed.
The patch resolves#55703. The LIT test (debug_scope_distinct.swift) is the
reproducer from that issue.
For the size argument of an alloca, some targets use a i32 bit integer, some use
a 64 bit integer; the updated test was hard-coding i64, which caused it to fail
in other targets. This is irrelevant for what the test is doing, so we remove
that.
The previous lazy discovery did not always work because sometimes a debug_value
is emitted before the first SIL instruction in the variable's scope.
rdar://110841130
ConditionalClauseInitializerScope often create redundant scopes, however, they
are needed to correctly represent the scopes in an expression such as:
if case .something(let foo), let foo = foo.
This patch changes SILGen to lower them 1:1 from ASTScopes.
rdar://110841130
Based on https://github.com/apple/swift/pull/66409
With the observation that the pre-opaque world was using bitcast as an
indication that the storage type and the type of the variable were
different. We can recover this information from the storage type of the
alloca and the storage type of the type info.
Variable debug info is triggered by pattern bindings, however, inside a closure
capture list, this should be avoided by setting the appropriate flag in the
initializer object.
rdar://110329894
When a metadata pack is heap allocated, the pointer's LSB is set.
But lldb is expecting a real pointer. So mask it off.
Companion PR has a test: https://github.com/apple/llvm-project/pull/6961
rdar://110195273
Calls to getters are implicit because the compiler inserts them on a property
access, but the location is useful in backtraces so it should be preserved.
rdar://109123395
The previous code made the assumption that the ASTScope for a variable
declaration should be the one of the declaration's source location. That is not
necessarily the case, in some cases it should be an ancestor scope. This patch
introduces a map from ValueDecl -> ASTScope that is derived from querying each
ASTScope for its locals, which matches also what happens in name lookup. This
patch also fixes the nesting of SILDebugScopes created for guard statement
bodies, which are incorrectly nested in the ASTScope hierarchy.
rdar://108940570
On macOS it is possible for one application to contain Swift modules compiled
for different triples that are incompatible as far as the Swift compiler is
concerned. Examples include an iOS simulator application hunning on a macOS
host, or a macCatalyst application running on macOS. A debugger might see
.swift_ast sections for all triples at the same time. This patch adds an
interface to let the client provide a triple to filter Swift modules in an
ASTSection.
rdar://107869141
In an earlier version of the ASTScope -> SILdebugScope translation a workaround
was put into place that would select the current debug scope if an ASTScope was
marked as ignoreInDebugInfo. Removing this workaround makes the translation more
predictable as it eliminated the dependency on the current SILBuilder state. The
property wrapper tests still pass without this.
This uncovers a situations with let bindings where the SIL instructions are
emitted RHS before LHS, which does violate the di-hole verifier. This is
addressed by relaxing the verifier for now.
rdar://108736443
This is a revert of the workaround for creating debug info for error variables
in b2109ab4db, while leaving the test added back then in place. The compiler
is now emitting debug info for the error pattern binding as it's supposed to and
after the recent migration to stricter debug scope generation, there are now
situations where the variable added for the workaround and the correct one are
in conflict.
rdar://108576484
When compiling with interop enabled, emit the C++ interop compiler flag
into the DW_AT_APPLE_flags, to make it so LLDB can accurately match the
C++ interop mode when initializing its compiler instance.
rdar://97610458
(cherry picked from commit b1dbb0a321)
