Since https://reviews.llvm.org/D158638, entry values are only produced for
64-bit architectures. As such, related tests need to be guarded by the
appropriate REQUIRES directive.
This change passes through the -file-compilation-dir flag to the
ClangImporter instance as -ffile-compilation-dir. When used in
conjunction with https://github.com/llvm/llvm-project/pull/67744
this will allow for setting the compilation directory of pcm
files using the -file-compilation-dir flag.
When building and importing modules built with
`-fmodule-file-home-is-cwd` we should be setting the debug info
directory to the current working directory. This matches the
behavior in clang: https://reviews.llvm.org/D134911
Merge conflict while removing `nocapture` from
`s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF`. Resolution
was to remove nocapture from the expected output in both cases:
```
// CHECK-LABEL: define swiftcc void @"$s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF"(ptr noalias[-nocapture-] %0, ptr %T, ptr %T.P)
```
Conflict cause: 4858cb6225
This is the same as the original change to this file. The conflict seems
to be due to the next line changing, when moving from llvm.dbg.addr to
llvm.dbg.value.
Conflicts:
test/DebugInfo/move_function_dbginfo.swift
The use of 'nocapture' for parameters and return values is incorrect for C++ types, as they can actually capture a pointer into its own value (e.g. std::string in libstdc++)
rdar://115062687
The more awkward setup with pushGenericParams()/popGenericParams()
is required so that when demangling requirements and field types
we get the correct pack-ness for each type parameter. The pack-ness
is encoded as part of the generic signature, and not as part of
the type parameter mangling itself.
Fixes the ASTDemangler issue from rdar://problem/115459973.
KeyPath's getter/setter/hash/equals functions have their own calling
convention, which receives generic arguments and embedded indices from a
given KeyPath argument buffer.
The convention was previously implemented by:
1. Accepting an argument buffer as an UnsafeRawPointer and casting it to
indices tuple pointer in SIL.
2. Bind generic arguments info from the given argument buffer while emitting
prologue in IRGen by creating a new forwarding thunk.
This 2-phase lowering approach was not ideal, as it blocked KeyPath
projection optimization [^1], and also required having a target arch
specific signature lowering logic in SIL-level [^2].
This patch centralizes the KeyPath accessor calling convention logic to
IRGen, by introducing `@convention(keypath_accessor_XXX)` convention in
SIL and lowering it in IRGen. This change unblocks the KeyPath projection
optimization while capturing subscript indices, and also makes it easier
to support WebAssembly target.
[^1]: https://github.com/apple/swift/pull/28799
[^2]: https://forums.swift.org/t/wasm-support/16087/21
Disabling failing tests:
- DebugInfo/BridgingHeaderPCH.swift
- DebugInfo/ClangModuleBreadcrumbs.swift
Trying to get more visibility on Linux for rebranch status.
Radar to track fixing these test failures: rdar://114728459
When the function is a method, we want a DW_AT_declaration there.
Because there's no good way to cross the CU boundary to insert a nested
DISubprogram definition in one CU into a type defined in another CU when
doing LTO builds.
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.
The following tests required conflict resolutions, since upstream LLVM did a lot of
work to remove dbg.addr, and this work is not available to swift's main. At the
same time, swift's main changed these tests to enable opaque pointers.
```
both modified: test/DebugInfo/async-let-await.swift
both modified: test/DebugInfo/move_function_dbginfo.swift
both modified: test/DebugInfo/move_function_dbginfo_async.swift
```
The conflicts are fairly easy to fix: we keep the "structure" of the CHECK
lines present in `next`, but replace all pointers with `ptr`.
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
