[stable/21.x] Cherry-pick changes from previous stable branch #11027
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…:SupportIndirectSymViaGOTPCRel` The Swift compiler needs to disable this option in order for the standard library to link successfully on Linux. See: - #9339 - llvm#78003
This reverts commit 6fe29b9.
This reverts commit c00ada0.
…AKING_CHECKS" This reverts commit ce80c80. There's a number of clients in Swift (and our fork) that rely on `hash_value` being deterministic. We can add this back in after those are fixed.
This reverts commit 76cfe6c. Only running `ActOnEndOfTranslationUnit` when `enableIncrementalProcessing` was false was the only NFC part of splitting `-fincremental-extensions` and `enableIncrementalProcessing` again (68090ee). LLDB started failing after that change with: ``` /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/cstdlib:127:9: error: declaration of 'calloc' must be imported from module 'Darwin.malloc._malloc' before it is required ``` Reverting that part of the change fixed LLDB and didn't cause any other test failures, so happy days. Unfortunately most of what `Sema::ActOnEndOfTranslationUnit` does is additional diagnostics, which don't make a lot of sense from the Clang Importer in Swift. So this ends up being a significant regression if eg. `-warnings-as-errors` is enabled. Resolves rdar://116194950. (cherry picked from commit eed23a1)
… and merge the remaining code into is_convertible.h (llvm#137717)" This reverts commit e43e8ec.
…zg} (llvm#133920)" This reverts commit 9e3982d.
…vm#133937)" This reverts commit 703cfe7.
This reverts commit 67cb040. When importing headers, the Swift ClangImporter library depends on `clang::Parser::ParseTopLevelDecl` consuming an EOF token when `IncrementalProcessing` is set.
…ibute" (cherry picked from commit b6b282b)
LLVM currently emits dubious symbol sizes for aliases. E.g. assembling
the following with LLVM top-of-tree...
```
$ cat foo.s
<snip>
.data
.globl base
base:
.dword 42
.size base, 8
.set alias, base+4
```
results in both base and alias having symbol size 8, even alias starts at
base + 4. This also means that alias extends past the end of the .data
section in this example.
We should probably teach LLVM not to do this in the future, but as a short-term
fix this patch teaches JITLink to simply truncate symbols that would extend
past the end of their containing block.
rdar://114207607
(cherry picked from commit 6267697)
Conflicts:
llvm/lib/ExecutionEngine/JITLink/ELFLinkGraphBuilder.h
(cherry picked from commit 2f53a4c)
This change fixed the size of the symbol but the check that emited the error was still using the old size. Updated to use the correct size, which will make the code in the if unreachable, but it's probably better to leave it to avoid merge conflicts. rdar://133510063 (cherry picked from commit d629b38)
Swift is currently generating multiple .rodata sections with a combination of SHF_ALLOC and (SHF_ALLOC | SHF_WRITABLE) flags and this was tripping an assert in the ELFLinkGraphBuilder. As a temporary workaround this patch just uses the union of the requested permissions. rdar://114207428 (cherry picked from commit ead32e1) Conflicts: llvm/lib/ExecutionEngine/JITLink/ELFLinkGraphBuilder.h (cherry picked from commit a655fbe)
llvm#134887 added a clone for the compiler instance in `compileModuleAndReadASTImpl`, which would then be destroyed *after* the corresponding read in the importing instance. Swift has a `SwiftNameLookupExtension` module extension which updates (effectively) global state - populating the lookup table for a module on read and removing it when the module is destroyed. With newly cloned instance, we would then see: - Module compiled with cloned instance - Module read with importing instance - Lookup table for that module added - Cloned instance destroyed - Module from that cloned instance destroyed - Lookup table for that module name removed Depending on the original semantics is incredibly fragile, but for now it's good enough to ensure that the read in the importing instance is after the cloned instanced is destroyed. Ideally we'd only ever add to the lookup tables in the original importing instance, never its clones.
|
@swift-ci please test llvm |
bnbarham
approved these changes
Jul 18, 2025
|
Thanks @AnthonyLatsis ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-picks:
swift_nameattr… #10984