Fix platform filter handling for binary target build files

[yimajo]

For binary targets, this change removes the incorrect assert for platform filters and applies the union of the platform filters to the returned BuildFile.

Motivation

When an app uses a Swift package that depends on a binary target, running Swift Build with assertions enabled fails at the following assertion:

swift-build/Sources/SWBTaskConstruction/TaskProducers/BuildPhaseTaskProducers/SwiftPackageCopyFilesTaskProducer.swift

Line 185 in 99885a7

assert(aggregatedPlatformFilters.isEmpty)

The issue can be reproduced with the following Package.swift:

// swift-tools-version: 6.3
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "MyLibrary",
    platforms: [
        .macOS(.v26),
        .iOS(.v26),
    ],
    products: [
        .library(
            name: "PackageProduct",
            targets: [
                "FeatureMacOS",
            ]
        ),
        .library(
            name: "PackageProductMacOSAndIOS",
            targets: [
                "FeatureIOS",
            ]
        ),
    ],
    targets: [
        // MARK: -
        .target(
            name: "FeatureIOS",
            dependencies: [
                .target(
                    name: "GoogleAppMeasurement",
                    condition: .when(platforms: [.iOS, .macOS])
                ),
            ]
        ),

        .target(
            name: "FeatureMacOS",
            dependencies: [
                .target(
                    name: "GoogleAppMeasurement",
                    condition: .when(platforms: [.macOS])
                ),
            ]
        ),

        .binaryTarget(
            name: "GoogleAppMeasurement",
            url: "https://dl.google.com/firebase/ios/swiftpm/12.17.0/GoogleAppMeasurement.zip",
            checksum: "5bf58d72ecbb6a84e0a64f8557c4488f7812c1742d409eb712033bc7edc95992"
        ),
    ],
    swiftLanguageModes: [.v6]
)

The issue can be reproduced by linking both package products from an app.

A target that depends on a binary target can specify platform conditions using .when(platforms:). SwiftPM carries these conditions as platformFilters on the corresponding BuildFiles.

In this example, the same binary target is reached through two package products with different platform filters. Both dependency paths participate in a macOS build, so aggregatedPlatformFilters is nonempty and the assertion fails.

Changes

Removing assert(aggregatedPlatformFilters.isEmpty) is sufficient to prevent the assertion failure. However, returning firstBuildFile unchanged would preserve only one set of platform filters and discard the aggregated union.

This change:

• Removes assert(aggregatedPlatformFilters.isEmpty).
• Applies aggregatedPlatformFilters to the returned BuildFile for binary targets.
• Preserves assert(aggregatedBuildConfigurationFilters.isEmpty), because SwiftPM does not support conditionalizing a binary-target dependency by build configuration.
• Rewrites the BuildableItem branching as a switch.
• Keeps returning firstBuildFile if a .targetProduct cannot be resolved, while using assertionFailure to report the violated invariant when assertions are enabled.

Testing

Added SwiftPackageCopyFilesTaskProducerTests.packageBinaryXCFrameworkPlatformFiltersAreAggregated().

The test verifies that SwiftPackageCopyFilesTaskProducer.buildFilesForPackages(context:frameworksBuildPhase:) returns a BuildFile containing the union of the macOS, iOS, and iOS Simulator platform filters.

[yimajo]

@swift-ci test

[owenv]

Thanks. This looks good to me, but I think we should future proof build configuration filters too to avoid a similar regression in the future

[owenv]

The intent is that eventually binary targets could condition on build configuration as well, so I think we should drop this assert at the same time to future proof things.

[yimajo]

Just to clarify, do you mean that I should only remove the assertion for now, or also apply aggregatedBuildConfigurationFilters to the returned BuildFile by extending with(...) as follows?

 case .reference, .namedReference:
-    // Binary targets do not support build configuration filters.
-    assert(aggregatedBuildConfigurationFilters.isEmpty)
     return firstBuildFile.with(
-        platformFilters: aggregatedPlatformFilters
+        platformFilters: aggregatedPlatformFilters,
+        buildConfigurationFilters: aggregatedBuildConfigurationFilters
     )

[owenv]

I think we should extend with and also use the aggregatedBuildConfigurationFilters, so the two types of filters are handled consistently

[yimajo]

Thank you for the feedback. I’ve updated the implementation to aggregate build configuration filters as well and updated the test accordingly.

[owenv]

@swift-ci test

[owenv]

@yimajo By the way, if you're interested in getting CI access to start tests yourself, there's some information about that in https://www.swift.org/contributing/#contributing-code (the "Member" section) if you're not already aware. I think you probably qualify based on the PRs you've been submitting here.

[owenv]

@swift-ci test