unified: Hardcode swift_version

It seems that using swift_version_file has some issues when `codeql` is
consumed as a dependency module. I'm hoping hardcoding the version
instead will fix this, but ideally we should find a more robust
solution.

Author: tausbn

MODULE.bazel

@@ -229,12 +229,19 @@ use_repo(
 # Swift toolchain for building `unified/swift-syntax-rs`. On Linux we register
 # a hermetic swift.org toolchain as the exec toolchain; on macOS `rules_swift`
 # auto-registers `xcode_swift_toolchain` (host Xcode + OS-provided Swift
-# runtime), which is not hermetic. Version comes from
-# `unified/swift-syntax-rs/.swift-version`.
+# runtime), which is not hermetic.
+#
+# The version is pinned as a literal rather than read from
+# `unified/swift-syntax-rs/.swift-version` via `swift_version_file`: the latter
+# makes the extension `module_ctx.read` a `//unified/...` label, which fails to
+# resolve when this repo is consumed as a dependency module (`@@ql+`) whose
+# `unified/swift-syntax-rs` package is not loadable in that context. Keep this
+# in sync with `unified/swift-syntax-rs/.swift-version` (used by the `cargo`
+# build) and the `swift-syntax` release in `swift/Package.swift`.
 swift = use_extension("@rules_swift//swift:extensions.bzl", "swift")
 swift.toolchain(
     name = "swift_toolchain",
-    swift_version_file = "//unified/swift-syntax-rs:.swift-version",
+    swift_version = "6.3.2",
 )
 use_repo(
     swift,

unified/swift-syntax-rs/BUILD.bazel

@@ -3,10 +3,6 @@ load(":xcode_transition.bzl", "xcode_transition_swift_library")
 
 package(default_visibility = ["//visibility:public"])
 
-# Pinned Swift version, shared with `cargo` and `swift/Package.swift`.
-# Referenced by `swift.toolchain(swift_version_file = ...)` in //:MODULE.bazel.
-exports_files([".swift-version"])
-
 # Targets in this package require a Swift toolchain (Linux or macOS).
 # `select()` gives us OR-of-OSes; other platforms get marked incompatible
 # so `bazel build/test //...` skips them cleanly.

unified/swift-syntax-rs/README.md

@@ -155,15 +155,20 @@ Requirements:
   [`xcode_transition.bzl`](xcode_transition.bzl)), so other targets on macOS
   keep using Bazel's default CC toolchain.
 
-The Swift compiler version in [`.swift-version`](.swift-version) is kept in sync
-with the `swift-syntax` release pinned in `swift/Package.swift`. It is honored on
-**Linux**, where the hermetic swift.org Bazel toolchain
-(`swift.toolchain(swift_version_file = …)`) and the local `cargo`/`swift build`
-both read it. On **macOS** it is *not* honored by the Bazel build: `rules_swift`
-auto-registers the host `xcode_swift_toolchain`, which uses whichever Swift ships
-with the installed Xcode and ignores `.swift-version`. So the pinned version
-governs Linux (and local) builds, while the macOS compiler version depends on the
-host Xcode.
+The Swift compiler version is kept in sync across three places: the
+[`.swift-version`](.swift-version) file (read by the local `cargo`/`swift build`
+and by [swiftly](https://www.swift.org/swiftly/)), the literal `swift_version`
+pinned on `swift.toolchain(...)` in the root `MODULE.bazel` (the hermetic
+swift.org **Linux** Bazel toolchain), and the `swift-syntax` release in
+`swift/Package.swift`. On **macOS** the version is *not* pinned by the Bazel
+build: `rules_swift` auto-registers the host `xcode_swift_toolchain`, which uses
+whichever Swift ships with the installed Xcode. So the pin governs Linux (and
+local) builds, while the macOS compiler version depends on the host Xcode.
+
+(The Bazel toolchain pins a literal rather than reading `.swift-version` via
+`swift_version_file`, because the latter makes the module extension read a
+`//unified/...` label, which fails when this repo is consumed as a dependency
+module.)
 
 ## Usage