Skip to content

[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

Merged
merged 123 commits into from
Jul 20, 2024

Conversation

jmschonfeld
Copy link
Contributor

We will be landing the Foundation re-core in Swift 6. This brings all of the changes to main into the release/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 merging main into this branch), and we will merge to release/6.0 once all re-core work has landed

lxbndr and others added 30 commits December 25, 2023 14:39
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).
…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.
jmschonfeld and others added 13 commits June 28, 2024 09:55
* 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
@jmschonfeld
Copy link
Contributor Author

@swift-ci please test Linux platform

@jmschonfeld
Copy link
Contributor Author

@swift-ci please test Windows platform

@jmschonfeld
Copy link
Contributor Author

CMake Error at /home/build-user/cmake/Modules/ExternalProject.cmake:3114 (message):
  No download info given for 'swiftfoundationicu-populate' and its source
  directory:

   /home/build-user/swift-foundation-icu

  is not an existing non-empty directory.

@shahmishal is there something that we might be missing here to have the checkout work as expected for a release/6.0 PR?

@shahmishal
Copy link
Member

Did we cherry-pick the update-checkout changes on swift:release/6.0?

@jmschonfeld
Copy link
Contributor Author

Did we cherry-pick the update-checkout changes on swift:release/6.0?

Yes, but there isn't an explicit branch listed under the release/6.0 key in the json file - do we need to explicitly specify the branch or will it default to main?

@shahmishal
Copy link
Member

We will need cherry-pick the changes into release/6.0 branch otherwise the JSON file will not clone swift-foundation and swift-foundation-icu.

@jmschonfeld
Copy link
Contributor Author

swiftlang/swift#75338

@swift-ci please test

@jmschonfeld
Copy link
Contributor Author

Tests for this are now running on swiftlang/swift#75338 which updates the update-checkout config to correctly checkout the right repos

@parkera
Copy link
Contributor

parkera commented Jul 19, 2024

swiftlang/swift#75338

@swift-ci please test

@parkera
Copy link
Contributor

parkera commented Jul 20, 2024

Test at swiftlang/swift#75338 passed

@parkera parkera merged commit 085e789 into swiftlang:release/6.0 Jul 20, 2024
0 of 3 checks passed
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.