With the commit of the Catalina merge into 5.3, swift-corelibs-foundation is now more closely aligned to the behavior and functionality of macOS Catalina. (Up until 5.2, it was aligned to macOS Mojave.) I wanted to highlight this merge because it may have some effects you want to look out for:
Several changes have occurred to multiple Core Foundation components that correspond to bug fixes and performance improvements that also occurred in macOS Catalina.
URL parsing (through struct URL and NSURL) has changed to match the deprecation, and the new behavior, of NSURL.parameterString in macOS Catalina. (Parameter strings are no longer returned separately from that property, but as part of the .path.) On Apple platforms, this affects code that is built using the Catalina or iOS 13 SDK; on Swift for Linux, all application code is affected as soon as you upgrade to the Swift version that contains the new Foundation (e.g. by basing your Docker container on a newer image once available.)
Certain uses of NSString methods to examine strings that contain emoji that became available alongside Catalina and iOS 13 will now correctly match the behavior you'd expect when e.g. iterating substrings.
In general, starting with Swift 5.1, we have been much stricter about source compatibility in a way that matches more closely the Darwin approach: you will not see API disappear, but, rather, changes will be marked deprecated with replacements added much in the way API do when changed on Apple platforms. In cases like parameterString, deprecations that occur on Apple platforms will also eventually sync up like they did today.
While Linux is the focus of the announcement, this version of Foundation is available to all ports of Swift, and some care has been taken to avoid breaking builds for popular ports. Please let me know ASAP if you manage a platform port that requires corrective intervention in Foundation for building.
Thank you @millenomi for all the work in the update! And thank you for taking care of the other platforms in the update as well, it is greatly appreciated.
This has historically been the update cycle. The hope is to reduce the time to merge, and there has been a significant amount of behind-the-scenes work to make it happen faster, but there is no specific promise on cadence at this time.
In general, I will say that large merges like these introduce some risk considerations, and so will generally happen only on major Swift releases rather than e.g. as part of a monthly Linux release.
Implementations for missing API are always welcome. (Any missing API is a bug, though some API are not currently in the cross-platform subset due to a plethora of considerations. I usually comment case by case on PRs.)
/home/augusto/Developer/swift/swift-corelibs-foundation/CoreFoundation/String.subproj/CFString.c:3556:43: error: use of undeclared identifier 'UCHAR_EXTENDED_PICTOGRAPHIC'
return u_hasBinaryProperty(character, UCHAR_EXTENDED_PICTOGRAPHIC);
We are investigating an issue where certain Ubuntu CI configurations were using presets not building libicu as part of their build. They should now be corrected.
Except if you're working in very, very specific configurations (cc @drexin), and specifically if you're trying to build for Ubuntu the way the swift.org builds are built, we do not support running with older ICU versions. If you're working on Swift on your machine, either you pass --icu to build-script, or, more productively, you should use one of the buildbot presets rather than concocting your own set of flags. (I start my iterations building Swift with the Foundation PR preset, for example.)