-
Notifications
You must be signed in to change notification settings - Fork 10.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stdlib] Drop ICU #40340
[stdlib] Drop ICU #40340
Conversation
I really love this change, but I think that this needs a bit more work. I don't think we need to worry about the dependency in Foundation - the rest of the build will take care of that, it doesn't pull it in from swift itself, but rather through its own build. We can tweak the ordering subsequently, but there is more build cleanup that should be done. Off the top of my head, delete: We don't need to worry about the rest of the cleanup (i.e. build-script or build-script-impl) which need to pass the parameters around. That can be done subsequently and will only make a minor difference. The important part here is to clean up the large amount of cruft that is custom. |
"_ubrk_setText", "_ubrk_setUText", "_unorm2_getNFCInstance", | ||
"_unorm2_hasBoundaryBefore", "_unorm2_normalize", | ||
"_unorm2_spanQuickCheckYes", "_utext_openUChars", "_utext_openUTF8", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3 ^2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️ ❤️ ❤️
// Force an autolink with ICU | ||
#if defined(__MACH__) | ||
asm(".linker_option \"-licucore\"\n"); | ||
#endif // defined(__MACH__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the stdlib isn't doing this anymore, would importing Foundation need to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Foundation would, and already does so by means of injection. The need for this is strictly for static linking. When statically linking, the dependencies must be explicitly listed and this is a horrible workaround to avoid the user from having to specify that and the driver not learning the dependency. This can be safely removed IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/Foundation/CMakeLists.txt#L171-L182 for the hackery that I was referring to - the dependency is injected via the swift driver at compile time.
@@ -238,29 +237,6 @@ set(swift_core_link_flags "${SWIFT_RUNTIME_SWIFT_LINK_FLAGS}") | |||
set(swift_core_framework_depends) | |||
set(swift_core_private_link_libraries) | |||
set(swift_stdlib_compile_flags "${SWIFT_RUNTIME_SWIFT_COMPILE_FLAGS}") | |||
if(SWIFT_PRIMARY_VARIANT_SDK IN_LIST SWIFT_DARWIN_PLATFORMS) | |||
list(APPEND swift_core_link_flags "-all_load") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(from outside) Was ICU the only thing using -all_load
? Or is this something that can be removed separately? Or is it still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, ICU is the only think that the standard library links against (outside of system libraries like ... libSystem) explicitly. The rest of the dependencies that need to be linked against will be from the clang triggered auto-link. INCORPORATE_OBJECT_LIBRARIES
does properly use the TARGET_OBJECTS
generator to unpack the archive and link them so no unintentional DCE should occur.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was swiftRuntime.a itself I was worried about, but if that's going through INCORPORATE_OBJECT_LIBRARIES
then everything should be okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that is handled via the incorporate object libraries and so we don't need to worry about the potential DCE.
@swift-ci please test Windows platform |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for cleaning this up, I'm super excited to see this finally happening.
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love everything about this. Amazing work! ❤️
@@ -388,7 +388,7 @@ extension _StringGuts { | |||
_internalInvariant(self.isForeign) | |||
|
|||
// Both a fast-path for single-code-unit graphemes and validation: | |||
// ICU treats isolated surrogates as isolated graphemes | |||
// treat isolated surrogates as isolated graphemes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// treat isolated surrogates as isolated graphemes | |
// Treat isolated surrogates as isolated graphemes. |
Build failed |
Looks like the linux CI was unable to run the Foundation tests because of a missing dependency on ICU, looks like you'll need to fix Foundation too. |
Am I properly understand that Or this PR is only about build time dependencies, thus, assuming that concrete system will have shared library for runtime execution e.g. For example when targeting Android, the ICU needs to be renamed (e.g. Few Android examples:
|
@vgorloff, my understanding is that a series of pulls by @Azoy have already removed all external ICU dependencies from this repo, but that swift-corelibs-foundation still requires it: see comments above for more info. That's probably why this pull currently fails on the linux CI, because the foundation tests inadvertently relied on this CMake configuration. |
I’m curious about why it passed all the test on Windows😂 It seems Windows and Linux CI shared the same way of detecting and linking ICU. |
Both the macOS and Windows CI don't run the swift-corelibs-foundation tests, only the linux CI does. |
swiftlang/swift-corelibs-foundation#3118 @swift-ci please test |
Build failed |
The linux CI couldn't check out your new foundation pull for some reason, maybe spurious. |
swiftlang/swift-corelibs-foundation#3118 @swift-ci please clean test Linux |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work.
@swift-ci please clean test Linux |
@compnerd @buttaface this look good to go? |
LGTM, but please also let @buttaface have another look. |
LGTM |
[android] Remove ICU build flags since that requirement was dropped in #40340
…ilt separately This was dropped in #40340.
…ilt separately This was dropped in swiftlang#40340. (cherry picked from commit abe9225)
Now that the stdlib no longer needs ICU, let's drop the dependency 🙂
This is marked as a draft because right now this only removes the immediate dependency on the stdlib, and isn't touching any of the larger build rules. I wanted to get others opinions on how best to handle that (@compnerd @gottesmm ). I think some of the build rules in this repository are still needed for corelibs-foundation no?
Also, this updates the freestanding symbol list (@kubamracek ).
If there are others that you think I should cc please let me know!