Assorted fixes for runtime metadata mangling and demangling #78729
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
rjmccall
requested review from
mikeash,
al45tair and
DougGregor
as code owners
|
@swift-ci Please test |
tshortli
reviewed
Jan 18, 2025
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
15c164d to
27e40a6
Compare
|
@swift-ci Please test |
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
27e40a6 to
c564bd4
Compare
|
@swift-ci Please test |
hharck
reviewed
Jan 19, 2025
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
c564bd4 to
cfc7ff7
Compare
|
@swift-ci Please test |
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
cfc7ff7 to
10bce2a
Compare
|
@swift-ci Please test |
CodaFi
reviewed
Jan 21, 2025
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
10bce2a to
cefbff3
Compare
|
@swift-ci Please test |
much about the LLVM triple, but we can do our best on the Swift side.
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
b4f5647 to
2818875
Compare
|
@swift-ci Please test |
RuntimeVersions.def. This really *ought* to be NFC, but alas, there are two behavior changes. The first is that arbitrary future versions (short of the special future version of 99.99) used to be considered to be free of all deployment issues, but are now just considered to offer the Swift release that's attached to the last known release of the target platform. The old behavior was fine in a sense: deployment issues require updating the compiler anyway, so if you haven't taught the compiler that iOS 31 provides Swift 8.3, you probably also haven't taught it about any problems that are fixed in Swift 8.3. The only problem with this logic is that we often implement compiler fixes for these deployment issues before that first OS actually ships (and thus before we've settled on a release number), and so we end up with a race where we start considering new releases to fix the issue even without updating the release mapping. The new approach fixes this: we say that the bug will be fixed in Swift 8.3, and for the time being, there are simply no platforms that provide that fix yet. Later, we update the mapping to say that iOS 31 provides it, and compilations targeting that release will be able to take advantage. The other issue is that we actually treated "future" releases of macOS 10.x (starting with 10.16, which ended up being 11.0) the same way, instead of treating them logically as intermediate between 10.15 and 11.0. My initial attempt at this generation used a constexpr array of a struct with a std::initializer_list of platform releases, exactly mirroring the structure of the .def file and requiring the compiler to parse out the bits relevant to the target dynamically. The approach I ended up with is much better, but I was actually forced into it because MSVC miscompiled those global "temporary" arrays --- they ended up uninitialized.
with sending results: - The sending result mangling was added in the 6.0 runtime, so demangling cannot be used to produce this metadata when targeting an earlier runtime. - The combination of a sending result with isolation requires the 6.1 runtime to successfully demangle, due to a bug in the 6.0 demangler.
instead of the notional 10.24, which the old logic in Platform.cpp accidentally treated as a future release with no runtime restrictions.
rjmccall
force-pushed
the
isolated-sending-results-compiler-fix
branch
from
2818875 to
a4853f8
Compare
|
@swift-ci Please test |
|
@swift-ci Please test macOS |
|
@swift-ci Please test Linux |
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.
Primarily, teach the compiler to not use the runtime demangler to produce
@MainActor (...) -> sending Tand similar type metadata unless the deployment includes the bug fix in Swift 6.1. But I've also fixed the metadata-to-demangling-tree walk to preserve the@isolated(any)bit, and I've removed some code that was duplicating the information inRuntimeVersions.defand implicitly making aggressive assumptions about future OS releases.