Skip to content

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

Closed

Conversation

stephenverderame
Copy link

Since Metal 4 was announced, this change adds the Metal4 deployment target for MSL.

susmonteiro and others added 30 commits May 7, 2025 11:56
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
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
jansvoboda11 and others added 12 commits June 25, 2025 10:57
…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
…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.
@stephenverderame
Copy link
Author

@swift-ci test

Copy link
Collaborator

@owenv owenv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@owenv
Copy link
Collaborator

owenv commented Jul 1, 2025

@swift-ci test

@jakepetroules
Copy link
Collaborator

Shouldn't this go to release/6.2?

@stephenverderame
Copy link
Author

I was under the impression that it is supposed to go in main and release/6.2. Should it just be release/6.2?

@jakepetroules
Copy link
Collaborator

We're periodically merging release/6.2 to main so you can just land this directly on release/6.2 to start.

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.