With https://github.com/apple/llvm-project/pull/7787 merged, we can now finally
renable these tests, as the x86 swift async handling should be properly
preserved by the x86 instruction selector.
These tests contained some incorrect checks from a time where it was expecting
an entry value even in the entry funclet of coroutines. For example, it had
this:
```
CHECK-NEXT: [[ASYNC_REG:DW_OP_.*], DW_OP_plus_uconst 0x10, DW_OP_plus_uconst 0x8,
DW_OP_deref
```
Which tries to find some "async reg", but really matches anything. It worked by
accident on arm, but not on x86. The correct check is simply:
```
CHECK-NOT: OP_entry_value
```
Replace the generation of debug info for enums from DW_TAG_union_type
to either DW_TAG_enumeration_type or DW_TAG_variant_part, as these
representation match Swift enums more closely.
This test had been disabled back in 2021:
https://github.com/apple/swift/pull/36479
With this commit, it should now pass.
We also add a 64-bit target requirement, since this test relies on entry_values
being produced.
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.
