fix: honor package level language mode configuration

[jflan-dd]

Ensure targets are built with the correct Swift language mode based on package level information.

Fixes #1743

[cgrindel]

I added a couple of formatting comments. Just let us know when tests are green and we can take another look.

[jflan-dd]

@cgrindel while working on the failing test I realized that despite the flexibility that the existing block of code around language modes would imply, the only feature that's actually supported by rules_swift is swift.enable_v6

Existing code:

rules_swift_package_manager/swiftpkg/internal/swiftpkg_build_files.bzl

Lines 144 to 151 in 0eef504

	for bs in target.swift_settings.language_modes:
	for language_mode in lists.flatten(bzl_selects.new_from_build_setting(bs)):
	new_language_mode = bzl_selects.new(
	value = "swift.enable_v" + language_mode.value,
	kind = language_mode.kind,
	condition = language_mode.condition,
	)
	features.append(new_language_mode)

As a result we can enforce that packages that use Swift 6 language mode are correctly compiled, but we can't use that feature flag to force a package down to language mode 5 if the main project has set swift.enable_v6.

In order to force a package down to language mode 5 we'd have to append -swift-version 5 to copts. Do you think that's something we should support?

[cgrindel]

In order to force a package down to language mode 5 we'd have to append -swift-version 5 to copts. Do you think that's something we should support?

@jflan-dd I am not sure.

@brentleyjones @luispadron @jpsim Do you have any thoughts?

[jflan-dd]

I think we should support pinning the language mode down to Swift 5 and only use -swift-version X to set the package language mode by removing the use of swift.enable_v6

The v6 feature potentially has other effects if the user isn't using the Swift 6+ compiler that package authors wouldn't expect.

# If this feature is enabled, the toolchain should enable the features that are
# available in Swift 6 language mode. If the toolchain supports
# `-swift-version 6`, it will do so using that flag. If it is older, it will
# enable the set of upcoming features that will be on by default in Swift 6,
# allowing users to prepare their code base by opting in to the full set of
# Swift 6 features even before switching to a Swift 6 compiler.

https://github.com/bazelbuild/rules_swift/blob/ccebe4dc4ac16ea45ef111bee33f31036027ac08/swift/internal/feature_names.bzl#L33-L39

I believe if the package used swiftLanguageVersions: [.version("6"), .v5] as documented in the the migration guide while using the Swift 5 compiler then we'd end up setting the swift.enable_v6 feature which would enable a bunch of language features that the package author didn't expect to be enabled for the Swift 5 compiler.

[cgrindel]

@jflan-dd Sounds reasonable to me. Is there anything else that you want to add to this PR before we merge?

[jflan-dd]

@cgrindel I pushed a commit to use only -swift-version X for setting the Swift language mode.

I don't have any other changes for this PR unless there's additional feedback during review.

[cgrindel]

@Mergifyio queue

[mergify]

queue

🛑 The pull request has been removed from the queue default

The pull request can't be updated.

You can take a look at Queue: Embarked in merge queue check runs for more details about the failure.

[mergify]

This pull request has been removed from the queue for the following reason: pull request branch update failed.

The pull request can't be updated.

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[cgrindel]

@Mergifyio queue

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at def3045