-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[6.0] Merge Foundation re-core to release/6.0 #5011
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
[6.0] Merge Foundation re-core to release/6.0 #5011
Conversation
CURL documentation (https://curl.se/libcurl/c/CURLMOPT_TIMERFUNCTION.html) explicitly says that the timer should be one-time. We basically have to follow CURL requests for setting, resetting and disarming such timers. Current logic eventually leaves a 1ms repeating timer forever, because CURL assumes it fires once, and may not ask us to remove it explicitly. Also, being used as request timeout trigger, this timer also has no sense to be repeated.
Extends socket lifetime enough to let DispatchSource cancel properly. Also prevents from creating new DispatchSources while other are in the middle of cancelling. Also includes tests (see swiftlang#4854 for test details).
…with the toolchain, by renaming the module
…iftlang#4872) From Clang 15, nested static initializer inside statement-expression is no longer a constant-time expression (See https://reviews.llvm.org/D127201). OSS Foundation defines `CFSTR` as a macro rather than `__builtin___CFStringMakeConstantString` and it uses nested static initializer inside statement-expression, so we can't assume `CFSTR` itself is always a constant-time expression. This patch removes some `static` qualifiers associated with `CFSTR` to make them acceptable with Clang 15 and later.
* Various fixes to allow for building on Windows * Enable shared libraries by default * Resolve Windows compiler flag warnings and fix constant string symbols
* Use FSR for Process executable path on Windows * Use FSR on Linux as well
We have been running into modularization issues on newer versions of various Linux distros, resulting in the compiler saying that the Glibc module doesn't have a SOCK_STREAM or SOCK_DGRAM. From some poking around, the definition is now coming from the CoreFoundation module as far as Swift is concerned. This is ultimately because our modulemap for Glibc is bad, but also means that I can't bring up Swift 6 on all of the Linux distros that 5.10 has support for. This workaround removes the explicit module name from `SOCK_STREAM` and renames it to `FOUNDATION_SOCK_STREAM` to avoid an ambiguous name, and completely removes `SOCK_DGRAM`. Both SOCK_STREAM and SOCK_DGRAM are fileprivates, so changing them will have no visible external effect. It is true that if another header somewhere defines `SOCK_STREAM`, we may pick it up instead of the definition from the glibc module, but that will also cause some nasty surprises to anyone using that header in C, so it is unlikely. Fixes: rdar://128079849
Fix the include path to Dispatch in Package.swift
Re-core Foundation on top of swift-foundation (merge package branch into main)
Allocate buffer of correct size in `NSURL.fileSystemRepresentation` on Windows
…d-broken-modulemap Workaround broken glibc modulemap
@swift-ci please test Linux platform |
@swift-ci please test Windows platform |
@shahmishal is there something that we might be missing here to have the checkout work as expected for a |
Did we cherry-pick the update-checkout changes on swift:release/6.0? |
Yes, but there isn't an explicit branch listed under the |
We will need cherry-pick the changes into |
@swift-ci please test |
Tests for this are now running on swiftlang/swift#75338 which updates the |
@swift-ci please test |
Test at swiftlang/swift#75338 passed |
We will be landing the Foundation re-core in Swift 6. This brings all of the changes to
main
into therelease/6.0
branch in order to lower that recore into Swift 6. This will be a WIP PR that we'll continue to update as we merge work to main (we'll keep mergingmain
into this branch), and we will merge torelease/6.0
once all re-core work has landed