-
Notifications
You must be signed in to change notification settings - Fork 190
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
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* 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
* 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”
`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.
…pty path and host (#1282)
* Revert RegexBuilder workaround * Cleanup private * Move off of RegexBuilder
…use identity casts (#1290)
* Update concurrency-safe notifications proposal (v4) * Update status for SF-0011 for second review --------- Co-authored-by: Charles Hu <charles@hu.codes>
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
@swift-ci please test |
parkera
approved these changes
May 19, 2025
This was referenced May 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.