Skip to content
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

Merged
merged 3 commits into from
Dec 7, 2021
Merged

[stdlib] Drop ICU #40340

merged 3 commits into from
Dec 7, 2021

Conversation

Azoy
Copy link
Contributor

@Azoy Azoy commented Nov 30, 2021

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!

update freestanding deps
@compnerd
Copy link
Member

compnerd commented Nov 30, 2021

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:
https://github.com/apple/swift/blob/main/CMakeLists.txt#L1021-L1050
https://github.com/apple/swift/blob/main/cmake/modules/SwiftConfigureSDK.cmake#L68-L75
https://github.com/apple/swift/blob/main/stdlib/cmake/modules/AddSwiftStdlib.cmake#L464-L473
https://github.com/apple/swift/blob/main/stdlib/cmake/modules/AddSwiftStdlib.cmake#L1316-L1318
https://github.com/apple/swift/blob/main/cmake/modules/FindICU.cmake

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",
]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<3

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<3 ^2

Copy link
Member

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__)
Copy link
Member

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?

Copy link
Member

@compnerd compnerd Nov 30, 2021

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.

Copy link
Member

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")
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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.

@compnerd
Copy link
Member

@swift-ci please test Windows platform

Copy link
Member

@compnerd compnerd left a 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.

@Azoy
Copy link
Contributor Author

Azoy commented Dec 1, 2021

@swift-ci please test

Copy link
Contributor

@gwynne gwynne left a 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
Copy link
Contributor

@gwynne gwynne Dec 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// treat isolated surrogates as isolated graphemes
// Treat isolated surrogates as isolated graphemes.

@swift-ci
Copy link
Contributor

swift-ci commented Dec 1, 2021

Build failed
Swift Test Linux Platform
Git Sha - 86fec40

@finagolfin
Copy link
Member

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.

@vgorloff
Copy link
Contributor

vgorloff commented Dec 2, 2021

Am I properly understand that stdlib (from git repository https://github.com/apple/swift.git) and libFoundation (from git repository https://github.com/apple/swift-corelibs-foundation.git) will not have build time and runtime dependencies on ICU?

Or this PR is only about build time dependencies, thus, assuming that concrete system will have shared library for runtime execution e.g. libicui18n.so?

For example when targeting Android, the ICU needs to be renamed (e.g. libicui18n.so -> libicui18nswift.so) to avoid conflicts with system provided version of ICU (which might be too old).

Few Android examples:

@finagolfin
Copy link
Member

@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.

@stevapple
Copy link
Contributor

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.

@finagolfin
Copy link
Member

Both the macOS and Windows CI don't run the swift-corelibs-foundation tests, only the linux CI does.

@Azoy
Copy link
Contributor Author

Azoy commented Dec 4, 2021

@swift-ci
Copy link
Contributor

swift-ci commented Dec 4, 2021

Build failed
Swift Test Linux Platform
Git Sha - 4fbbd0c054669d3b2ab08fddb751eba1cc116dc1

@finagolfin
Copy link
Member

The linux CI couldn't check out your new foundation pull for some reason, maybe spurious.

@Azoy
Copy link
Contributor Author

Azoy commented Dec 4, 2021

swiftlang/swift-corelibs-foundation#3118

@swift-ci please clean test Linux

Copy link
Member

@finagolfin finagolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work.

@Azoy Azoy marked this pull request as ready for review December 4, 2021 11:06
@Azoy
Copy link
Contributor Author

Azoy commented Dec 6, 2021

@swift-ci please clean test Linux

@Azoy
Copy link
Contributor Author

Azoy commented Dec 7, 2021

@compnerd @buttaface this look good to go?

@compnerd
Copy link
Member

compnerd commented Dec 7, 2021

LGTM, but please also let @buttaface have another look.

@finagolfin
Copy link
Member

LGTM

@Azoy Azoy merged commit 8a5f728 into swiftlang:main Dec 7, 2021
@Azoy Azoy deleted the drop-icu branch December 7, 2021 09:44
compnerd added a commit that referenced this pull request Dec 23, 2021
[android] Remove ICU build flags since that requirement was dropped in #40340
finagolfin added a commit that referenced this pull request Jan 17, 2025
rjmansfield pushed a commit to rjmansfield/swift that referenced this pull request Feb 10, 2025
…ilt separately

This was dropped in swiftlang#40340.

(cherry picked from commit abe9225)
finagolfin added a commit that referenced this pull request Feb 25, 2025
…ilt separately (#79274)

This was dropped in #40340.

(cherry picked from commit abe9225)

Co-authored-by: Finagolfin <finagolfin@tuta.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants