-
Notifications
You must be signed in to change notification settings - Fork 99
Add Metal 4 Deployment Target #625
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
Add Metal 4 Deployment Target #625
Conversation
Update automerger PR workflow
This is required for System.FilePath to work correctly on Windows in release mode.
Have the fallback logic specify the type of developer directory as well as just the location, and eliminate the initialization distinction on whether a Core was initialized with a "fallback" path vs one explicitly given, since it shouldn't matter.
…rdening-swift [Swift C++ Interop] Propagate hardening build setting to Swift
When working with SwiftBuild, there is a particular version that development is expected to use so that all of the compilers, standard libraries, test frameworks, etc. are expected to be working. The `.swift-version` file establishes a standard way to record this information. Also, there is tooling available through `swiftly` to use that information to automatically use the correct toolchain in any git commit to set the developer's toolchain when they run and test the package functions at desk. Create the `.swift-version` file and set it to the current expected toolchain version: 6.1.
Noticed this while working on some other tests; probably doesn't matter but may be confusing so correct it.
This allows projects to build more smoothly across platforms when architectures like arm64e are unconditionally appended to ARCHS. Simulators have never supported arm64e in any capacity. rdar://123839235
- Add a canonical implementation of reconstructing a build backtrace to the SwiftBuild module for use by clients - Adopt it in the unit test infrastructure - Improve backtrace reconstruction for dynamic tasks rdar://152194560
This provides a user-visible error message when attempting to initialize a Core with an older version, and removes the explicit version listing from the README so it doesn't need to be updated in multiple places.
License header check should ignore .swift-version
…ch (swiftlang#409)" This reverts commit 2fa7228.
This is mostly declarative right now, but does inform implicit dependencies.
…2025-06-02_09-02 Merge `release/6.2` into `main`
- Clarify frame descriptions based on feedback - expose public API for rendering a backtrace as text rdar://152194638
The original `AsyncOperationQueue` was ported in to `swift-package-manager`, where it was updated to support cancellation. This patch backports it to `swift-build` so that the two implementations are the same.
…traces Improve task backtraces for dynamic tasks
…S does There's a few spots where SWIFT_INCLUDE_PATHS is being used but SWIFT_SYSTEM_INCLUDE_PATHS isn't. Add those. rdar://152384124
…iptions Improve printed descriptions of task backtraces
…INCLUDE_PATHS SWIFT_SYSTEM_INCLUDE_PATHS doesn't work everywhere SWIFT_INCLUDE_PATHS does
…oding Fix BuildRequest encoding of the recordBuildBacktraces key
Now that llbuild has fork/exec support, the tests can be enabled on Amazon Linux 2, OpenBSD, etc.
…gs (swiftlang#513) This can be used to emit fix-its for XCConfigs files during the build process.
swift-build needs to support older versions of swift-frontend that don't support -Isystem. Check the driver and front end before using it. Also set TEST_LIBRARY_SEARCH_PATHS in SWIFT_SYSTEM_INCLUDE_PATHS rather than SWIFT_INCLUDE_PATHS, to match the handling for TEST_FRAMEWORK_SEARCH_PATHS -> SYSTEM_FRAMEWORK_SEARCH_PATHS. rdar://152540600
…ets are compatible
…aders Let's remove the `requires objc` from the module map file generated for the compatibility header. This condition triggered an error when importing the compatibility header from a C source file. This declaration is superfluous, the compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import the current compatibility header even if they may not see any content. Let's lift this restriction. It isn't currently necessary and we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C.
…toolchain-comparison Fix toolchain stack equality checks when checking if specialized targets are compatible
…kage-compilation-caching rdar://154310191 Enable compilation caching for Swift packages
…he given target's sources
…2025-06-30_09-02 Merge `release/6.2` into `main`
Allow setting LINKER_DRIVER=auto to choose an appropriate value for the target sources
Don't require objc in modulemaps generated for Swift compatibility headers
Allow downgrading API breakage errors to warnings
Adds the Metal4 deployment target for MSL.
@swift-ci test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
@swift-ci test |
Shouldn't this go to release/6.2? |
I was under the impression that it is supposed to go in |
We're periodically merging release/6.2 to main so you can just land this directly on release/6.2 to start. |
Since Metal 4 was announced, this change adds the Metal4 deployment target for MSL.