Build CompatibilitySpan shim #79703
Build CompatibilitySpan shim #79703
Conversation
slavapestov
force-pushed
the
span-backward-deployment
branch
3 times, most recently
from
4d8b499 to
5397c61
Compare
slavapestov
changed the title
slavapestov
force-pushed
the
span-backward-deployment
branch
3 times, most recently
from
ee2d77a to
0a6f54f
Compare
slavapestov
requested review from
rjmccall,
a team,
xymus,
adrian-prantl,
hborla,
xedin and
tshortli
as code owners
slavapestov
force-pushed
the
span-backward-deployment
branch
2 times, most recently
from
8a3d88b to
e6e4e51
Compare
| # stdlib/toolchain/Compatibility62. When running a binary with an old | ||
| # standard library, this dynamic library must be present at run time. | ||
| # | ||
| if(CMAKE_SYSTEM_NAME STREQUAL "Darwin") |
There was a problem hiding this comment.
You should sync up with @etcwilde about also building this with the newer build system
There was a problem hiding this comment.
The compatibility libraries will be split out in the new build since they need to be built exactly as they were to match the original version. We don't want changes to the Swift or C++ version to impact them.
|
I'm going to try an experiment suggested by @DougGregor before I land this where we replace the symlink with a dummy dylib, but let's see what happens with a CI toolchain build in the meantime... |
| // A handful of standard library stubs to allow Span.swift and RawSpan.swift | ||
| // to be compiled as part of the compatibility shim. |
There was a problem hiding this comment.
That's clever. So long we're not creating any public symbols here, this approach seems good. We could possibly pare this down further by breaking up the Span.swift/RawSpan.swift files into the ABI-affecting parts (that need to be included here) and the non-ABI-affecting parts.... but I think that's potentially easy to mess up.
There was a problem hiding this comment.
I was thinking as long as the implementation/API of Span is still in flux, it's best to build the actual source files from the stdlib. But eventually we might want to fork the shim's version of the code like you say because the @_aeic declarations don't need to be included at all.
There was a problem hiding this comment.
Yeah. We can fork after the Swift 6.2 version is finalized, so we don't accidentally change back-deployed version afterward.
This dynamic library contains a copy of the standard library's exported entry points for the Span and RawSpan types. This will allow backward deployment of code that uses those new types.
… linker directive purposes The module name changes the symbol mangling, and also causes TBDGen to emit linker directives. To separate out these two behaviors, introduce a terrible hack. If the module name contains a semicolon (`;`), the part before the semicolon is the module name for mangling, and the part after the semicolon is the module name for linker directives. If there is no semicolon, both module names are identical, and the behavior is the same as before.
It doesn't change anything about how we interpret the interface.
slavapestov
force-pushed
the
span-backward-deployment
branch
from
e6e4e51 to
b0627e2
Compare
|
@swift-ci Please test |
This PR allows the implementation of Span and RawSpan to be built as a standalone dynamic library, exporting the same symbol names as the standard library implementation of those types.
The actual
libswiftCompatibilitySpan.dylibgoes in<build dir>/lib/swift-6.2/$OS. We also create a symbolic link in<build dir>/lib/swift/$OS, fromlibswiftCompatibilitySpan.dylibtolibswiftCore.dylib.The missing piece is generating the correct
$ld$previoussymbols inlibswiftCore.dylib. I'm going to do that in a separate pull request.