Skip to content

Merge main into release/6.2 #1300

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 40 commits into from
May 19, 2025
Merged

Conversation

github-actions[bot]
Copy link

This PR was automatically opened by a GitHub action. Review the changes included in this PR and determine if they should be included in the release branch. If yes, merge the PR. Otherwise revert changes that should not be included on this branch.

parkera and others added 30 commits April 4, 2025 13:58
* ISO8601 DateComponents style

* Add Hashable to ISO8601FormatStyle
* Advise porter on where to make necessary change.

In #1075 the change was already made for BSD (thank you!); my working
edit had this guidance to ensure future porters get an error directing
them where to make a necessary change.

Otherwise, the FoundationEssentials build will fail and complain these
variables are not defined but not have guidance as to where they are
sourced from.

* OpenBSD does not support extended attributes.

* OpenBSD does not have secure_getenv.

* Remaining OpenBSD changes.

* OpenBSD also needs `pthread_mutex_t?`.

* Originally I followed Darwin's check with `d_namlen`, but this should
  work too.

* Correct statvfs type casts for OpenBSD.

On OpenBSD, fsblkcnt_t -- the type of f_blocks -- is a UInt64; therefore,
so must `blockSize` be.

Ultimately, both sides of the `totalSizeBytes` multiplication should
probably be type cast for all platforms, but that's a more significant
functional change for another time.

* Default activeProcessorCount to 1, not 0.

After a rather tedious debugging session trying to figure out why
swiftpm-bootstrap appeared to be deadlocked, this turned out to be the
culprit. Perhaps this should be #error instead, but for now, set a
sensible default.

* Use sysconf for activeProcessorCount.

This is what Dispatch does in some places for OpenBSD anyway, so do
likewise here.
* implementation

* address review
…stems (#1246)

GetBinaryType will return ERROR_BAD_EXE_FORMAT when querying an arm64 executable from an x86 process running on an ARM system. This change switches the implementation to use SHGetFileInfoW, which isn't subject to this quirk.

This also makes isExecutableFile behave more similarly to other platforms -- e.g. isExecutableFile already returns true for any file with the execute bit, even for an arm64 executable on an x86_64 macOS system (which it can't actually run). The spirit of the API is that the file is of an executable type, not necessarily that the running system is capable of executing it.

The practical consequence of fixing this bug is that queries like:

```swift
FileManager.default.isExecutableFile(atPath: "C:\\Windows\\system32\\cmd.exe")
```

will now correctly return true regardless of what architecture the binary is compiled for or what type of system it's running on.

Closes #860
* (146349351) Support NS/CFURL re-core in Swift

* Fix .fileSystemPath() calls in Windows test

* Use encoded strings for .absoluteURL, fix NSURL bridging and CFURL lastPathComponent edge cases

* Add workaround for crash on Linux

* Fix typo
Those constants are not used on WASI in Swift side, so there's no
need to require them in the C headers.
* add the writing direction attribute proposal

* add alternatives considered for wiritng direction cases and naming

* update status and implementation

* Update and rename NNNN-writing-direction-attribute.md to 0022-writing-direction-attribute.md

---------

Co-authored-by: Jeremy Schonfeld <jschonfeld@apple.com>
* Initial implementation.

* Cleanup and fix normalizedAddingPercentEncoding()

* Use failing initializer on URL instead of makeURL()

* Add standard copyright header

* Mark helper functions as fileprivate

* URL.Template.init() needs to be failable

* Rename InvalidTemplateExpression → URL.Template.InvalidExpression

* Add missing @available

* Update copyright header

* Convert tests XCTest → Swift Testing

* Use UInt8.isValidHexDigit

* Use URLParser.swift methods for unreserved + reserved characters

* Cleanup normalizedAddingPercentEncoding()

* Use String(decoding:as:)

* guard & white-space

* Cleanup “defer”

* Rename files URI… → URL…

* Add new files to CMakeLists.txt

* Add benchmarks.

* Add missing @available, 2

* Fix doc comment.

* Remove ExpressibleByStringLiteral conformance for URL.Template.VariableName

* Improve documentation comments

* Fix for  7b14d0b

* Fix doc comment

* Do not force unwrap “maximum length”
…1262)

#1198 added most of
the new files, but missed `URLTemplate_Expression.swift`, add it.
`TestSupport` already defines a typealias for `Expression` as `public typealias Expression = Foundation.Expression`. Therefore the top level typealias `private typealias Expression = URL.Template.Expression` caused an error when `TestSupport` is imported.

Move the typealias declaration to inside the test suite.
* ProgressReporter proposal

* reword future directions section + fix typo

* fix spacing

* refactor LocalizedDescriptionOptions

* edit future directions

* update ProgressReporter Pitch to V2

* update proposal to latest version

* fix spacing

* v3 updates

* Update review status for SF-0023 to active review

---------

Co-authored-by: Charles Hu <yizhe_hu@apple.com>
…path handling (#1257)

On Windows, there is a built-in maximum path limitation of 260 characters under most conditions. This can be extended to 32767 characters under either of the following two conditions:

- Adding the longPathAware attribute to the executable's manifest AND enabling the LongPathsEnabled system-wide registry key or group policy.
- Ensuring fully qualified paths passed to Win32 APIs are prefixed with \?\

Unfortunately, the former is not realistic for the Swift ecosystem, since it requires developers to have awareness of this specific Windows limitation, AND set longPathAware in their apps' manifest AND expect end users of those apps to change their system configuration.

Instead, this patch transparently prefixes all eligible paths in calls to Win32 APIs with the \?\ prefix to allow them to work with paths longer than 260 characters without requiring the caller of Foundation to manually prefix the paths.

See https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation for more info.
* [CI] Add support for GitHub Actions

* Disable License, Docs, Format, Unacceptable Lang, and API breakage checks

* Use Docker image for Windows builds

* update the CI to only run on nightly-main
* Implementation of #bundle macro

* separate macro declaration from implementation of bundle expansion

* Remove CurrentBundle.swift

---------

Co-authored-by: Andreas Neusuess <andreas_n@apple.com>
Signed-off-by: Jeremy Schonfeld <jschonfeld@apple.com>
Co-authored-by: Max Obermeier <m_obermeier@apple.com>
* [SF-NNNN] Markdown List Delimiters

* Add pitch link

* Update and rename NNNN-markdown-list-delimiters.md to 0025-markdown-list-delimiters.md
…ndows (#1277)

Instead of looping 8 times to work around the TOCTOU issue with sizing the current directory buffer, instead keep doubling the buffer up until the 32767 character limit until the result fits. This ensures we always get a working directory if GetWorkingDirectoryW didn't return some other error, rather than returning nil in the case of a race condition.
jrflat and others added 10 commits May 5, 2025 11:44
* Revert RegexBuilder workaround

* Cleanup private

* Move off of RegexBuilder
* Update concurrency-safe notifications proposal (v4)

* Update status for SF-0011 for second review

---------

Co-authored-by: Charles Hu <charles@hu.codes>
#1263)

* Reapply #1160

* Allow more than necessary padding characters

* Allow more than necessary padding characters in ignoreUnknownCharacters mode

* Removed `#if FOUNDATION_FRAMEWORK`
Musl's definition of `S_IFMT` gets imported by the Swift importer, which
means Swift can see `S_IFMT` as a `CInt` and also `S_IFMT` from the Swift
overlay as a `mode_t`.  The upshot is that attempting to convert it to
`mode_t` produces an ambiguity error, as Swift doesn't know which
definition to use.

rdar://147201087
@jmschonfeld jmschonfeld marked this pull request as ready for review May 19, 2025 16:22
@jmschonfeld
Copy link
Contributor

@swift-ci please test

@jmschonfeld jmschonfeld requested a review from parkera May 19, 2025 16:22
@parkera parkera merged commit 6c1b547 into release/6.2 May 19, 2025
4 checks passed
@parkera parkera deleted the automerge/merge-main-2025-05-19_09-00 branch May 19, 2025 17:51
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.