rdar://127279770
When an imported C type is over or under aligned, we did not use the alignment of the type, but computed the maximum alignment of its components, causing alignment issues in compact value witnesses.
AllocStackHoisting was losing debug info, including at -Onone.
When two alloc_stacks of the same type are merged, one of them
would lose their debug variable. It is now salvaged, with an added
debug_value.
This case was previously only handled for noncopyable types, it is
now done in all cases.
LoadableByAddress was losing debug info, including at -Onone.
When converting a load-store pair to a copy_addr, the debug info
attached to the load was not salvaged.
Additionally, the wrong scope was being attached to other debug
values.
api generation
This resolves the bug where apijson files recorded declarations as
unavailable purely because it was unavailable on a unrelated platforms.
Resolves: rdar://113552185
Resilence support will require changes to the Objective-C runtime to expand support for metadata initialization functions. Add a separate experimental feature flag to help with staging that support in, and modify diagnostics to not suggest increasing the minimum deployment target for now.
We really don’t need ‘em; we can just adjust the direct field offsets.
The runtime entry point currently uses a weird little hack that we will refactor away shortly.
When an @objc @implementation class requires the use of `ClassMetadataStrategy::Update` because some of its stored properties do not have fixed sizes, we adjust the direct field offsets during class realization by emitting a custom metadata update function which calls a new entry point in the Swift runtime. That entry point adjusts field offsets like `swift_updateClassMetadata2()`, but it only assumes that the class has Objective-C metadata, not Swift metadata.
This commit introduces an alternative mechanism which does the same thing without using any Swift-only metadata. It’s a rough implementation with important limitations:
• We’re currently using the field offset vector, which means that field offsets are being emitted into @objc @implementation classes; these will be removed.
• The new Swift runtime entry point duplicates a lot of `swift_updateClassMetadata2()`’s implementation; it will be refactored into something much smaller and more compact.
• Availability bounds for this feature have not yet been implemented.
Future commits in this PR will correct these issues.
IRGen sets up the `llvm::TargetOptions` by itself, rather than copying
them from the Clang instance (it has to do this, at present, because
Clang doesn't provide a way to get it to initialise one).
Unfortunately, it didn't set `UseInitArray`, which when linking with
GNU `ld` or `gold` is *fine* because those linkers automatically
convert `.ctors` and `.dtors` sections into `.init_array` and
`.fini_array` respectively. *However*, `lld` does *not* do this
conversion, so when using `lld`, if the compiler generates a
constructor or destructor function, it won't be called(!)
The fix is to set `UseInitArray` properly; I chose to copy the setting
from Clang, just in case Clang knows of a reason why it shouldn't be
`true`.
rdar://123504095
Without doing this, `__Swift_AST` gets stripped from the output.
We also need to call `IGM.finalize()` before `::performLLVM()` in the
`createSwiftModuleObjectFile()` function, so that we update the
section to mark it as retained.
rdar://123504095
We changed to `llvm.compiler.used` because of the behaviour of `gold`,
which refuses to coalesce sections that have different `SHF_GNU_RETAIN`
flags, which causes problems with metadata.
Originally I thought we were going to have to generate two sections
with distinct names and have the runtime look for both of them, but
it turns out that the runtime only wants to see sections that have
`SHF_GNU_RETAIN` in any case. It's really the reflection code that
is interested in being able to see non-retained sections. The upshot
is that we don't need to use `llvm.compiler.used`; it's just fine if
we have duplicate sections, as long as the reflection code looks for
them when it's inspecting an ELF image.
This also means we no longer need to pass `-z nostart-stop-gc` to the
linker if we're using `lld`.
rdar://123504095
rdar://126954341
C types don't have separate size and stride, but in type layouts we always computed the size as if they did. This could cause wrong offsets in compact value witnesses
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
Rather than having individual methods return without doing anything, arrange for ClassMetadataVisitor to never call them in the first place. This makes it so ClassMetadataScanner also knows which fields are omitted and it can compute offsets correctly.
The old logic is still present for field offsets to make this change NFC.
There is a debug-build-only verification that is done for
alloc_pack_metadata instructions that checks that there exist paired
dealloc_pack_metadata instructions which will be keyed off of to clean
up the on-stack variadic metadata packs corresponding to (the
instruction after) the alloc_pack_metadata.
StackNesting omits the deallocation instruction (as does
PackMetadataMarkerInserter) if it would be created in a dead end block.
If all blocks in the dominance frontier of the alloc_pack_metadata
instruction are dead-end blocks, then the verification will incorrectly
fail. It should not fail because it is not necessary to clean up the
on-stack pack metadata (or any other stack allocations) in such a case.
If all such blocks are dead-end blocks, however, the
alloc_pack_metadata's block itself is a dead-end block as well. So
during the verification, check whether the alloc_pack_metadata occurs in
a dead-end block and do not fail verification if it does.
rdar://125265980
Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
