[stdlib] Export ActiveTask symbol - #91067
Open
felipepiovezan wants to merge 1 commit into
Open
Conversation
Contributor
Author
|
@swift-ci test |
Contributor
|
+1, I think it is a better design to make the contract between LLDB and the runtime more explicit. |
Contributor
Author
|
On macOS: Likely unrelated Linux LLDB failures are expected, this needs to be tested with the matching LLDB PR. |
ktoso
approved these changes
Jul 30, 2026
ktoso
left a comment
ktoso
left a comment
Contributor
There was a problem hiding this comment.
This seems fine to me, lldb relies on this already if I understand correctly?
felipepiovezan
force-pushed
the
felipe/active_task_export
branch
from
July 30, 2026 07:48
ffed010 to
41ceb71
Compare
The debugger needs to access this variable when the concurrency library is compiled with ThreadLocalStorage enabled (Linux, Windows). Mangled names on anonymous namespaces are not reliable, and a file-scope local would not survive stripping the concurrency library of symbols (.symtab does not survive, whereas .dynsym does). In those platforms, this patch gives it protected visibility and a stable name. A consequence is that the variable is renamed _and_ moved outside the helper class on all platforms, since `extern C` and class statics are not compatible. This mostly cosmetic, with a very minor effect on encapsulation. On Windows, thread local + SWIFT_ATTRIBUTE_FOR_EXPORTS (dllexport) is not a valid combination. So we only give it a stable name, but this should suffice on that platform.
felipepiovezan
force-pushed
the
felipe/active_task_export
branch
from
July 30, 2026 07:49
41ceb71 to
6813078
Compare
Contributor
Author
Contributor
Author
Yup! This PR is just making sure we have a sound way of finding the symbol across all platforms/runtime implementations |
felipepiovezan
marked this pull request as ready for review
July 30, 2026 07:53
Contributor
Author
😞 |
Contributor
Author
|
@swift-ci test macos platform |
Contributor
Author
|
windows: |
Contributor
Author
|
@swift-ci test windows platform |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The debugger needs to access this variable when the concurrency library
is compiled with ThreadLocalStorage enabled (Linux, Windows). Mangled
names on anonymous namespaces are not reliable, and a file-scope local
would not survive stripping the concurrency library of symbols (.symtab
does not survive, whereas .dynsym does). In those platforms, this
patch gives it protected visibility and a stable name.
A consequence is that the variable is renamed and moved outside the
helper class on all platforms, since
extern Cand class statics arenot compatible. This mostly cosmetic, with a very minor effect on
encapsulation.
On Windows, thread local + SWIFT_ATTRIBUTE_FOR_EXPORTS (dllexport) is
not a valid combination. So we only give it a stable name, but this
should suffice on that platform.