Skip to content

Add support for the libswiftCompatibilitySpan.dylib backward deployment library #642

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DougGregor
Copy link
Member

The Swift library libswiftCompatibilitySpan.dylib allows uses of Span, MutableSpan, etc. to deploy to earlier OS versions. Detect when it is needed and copy it into the build artifact.

slavapestov and others added 2 commits July 3, 2025 14:26
A couple of related fixes:
* Use 26.0 as the fallback version number when SDKSettings doesn't include SwiftSpanMinimumDeploymentTarget
* Update tests to expect `--back-deploy-swift-span` and check when it shouldn't be there
@DougGregor
Copy link
Member Author

@swift-ci please test

@DougGregor
Copy link
Member Author

@swift-ci please test

@jakepetroules
Copy link
Collaborator

Note that we need this in release/6.2. You can either cherry pick it there afterwards, or land it in release/6.2 first and it'll be automatically forwarded to main.

Also, @slavapestov opened a PR for this a couple months ago (#359), I guess we should close that one now.

@DougGregor
Copy link
Member Author

Ah, I can replace this with one that targets release/6.2. Didn't realize that's how swift-build is handling branching.

@@ -287,6 +295,29 @@ extension Platform {

return version >= minimumSwiftConcurrencyVersion
}

/// Determines if the platform natively supports Swift 6.2's Span type. If `false`, then the Swift Span back-compat lib needs to be copied into the app/framework's bundle.
public func supportsSwiftSpanNatively(_ scope: MacroEvaluationScope, forceNextMajorVersion: Bool = false, considerTargetDeviceOSVersion: Bool = true) -> Bool? {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why add default values for the arguments? This is only ever called in one place.

default:
return (nil, nil)
return (nil, nil, "26.0")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just remove the case "macos", "macosx" now; that was a compatibility polyfill and isn't needed anymore.

@@ -283,6 +283,15 @@ extension Trait where Self == Testing.ConditionTrait {
})
}

package static func requireXcode26(sourceLocation: SourceLocation = #_sourceLocation) -> Self {
Copy link
Collaborator

Choose a reason for hiding this comment

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

The body of this function can just be implemented as requireMinimumXcodeBuildVersion("17A1", sourceLocation: sourceLocation)

@jakepetroules
Copy link
Collaborator

Ah, I can replace this with one that targets release/6.2. Didn't realize that's how swift-build is handling branching.

Yeah, we have a custom job set up... bit different from the rest of swiftlang.

FYI, you can just change the PR's target branch and force push without needing to open a new PR.

@jakepetroules
Copy link
Collaborator

jakepetroules commented Jul 4, 2025

The Windows failures:

× Test debuggableCommandLineTool() recorded an issue at BuildOperationTests.swift:390:17: Expectation failed: (executionResult.exitStatus → terminated with uncaught signal 309) == (.exit(0) → exited with status 0)

...look like STATUS_DLL_NOT_FOUND, meaning the binary that's running is failing to find some dependent DLL.

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.

3 participants