Swift settings are read by regex over any text: a commented-out `.treatAllWarnings(as: .error)`, a patch file name, `swift-tools-version: 6` despite `swiftLanguageModes: [.v5]`; ci-build-types demands sanitizers the sanitizers check skips

Start with the Swift patterns in project_validator/ecosystems/swift.py: COMPLETE_CONCURRENCY at lines 227-231, and the warnings-as-errors pattern at lines 247-255, which has no left-hand word boundary at line 250. Make the patterns ignore comments and respect an explicit swiftLanguageModes: [.v5], then add fixtures for the repro Package.swift files. Done means the vapor, Alamofire and SwiftLint cases produce the expected FAIL or PASS. The ci-build-types versus sanitizers mismatch needs a maintainer decision before code changes.

vapor's warnings-as-errors PASS comes from // .treatAllWarnings(as: .error) (Package.swift:262, commented out); SwiftLint's from the file name no-warnings-as-errors.patch (which removes the flag; the real setting is in a Bazel file); Alamofire is credited "complete concurrency checking" from swift-tools-version: 6.4 although swiftLanguageModes: [.v5] pins Swift 5 mode. Also inconsistent: ci-build-types FAILs every Swift combination for "missing + sanitizers" while sanitizers is skipped for Swift (swift build --sanitize=address|thread exists).

Evidence from the corpus audit

Alamofire/Alamofire / compiler-warnings

• kind: FALSE_POSITIVE
• actual: FAIL: Swift: missing Swift warning settings: SwiftLint with detail Swift: found complete concurrency checking
• expected: FAIL with missing ... SwiftLint, complete concurrency checking: the package is pinned to the Swift 5
  language mode, so Swift 6 complete checking is not on, and no -strict-concurrency=complete exists.
• evidence: Package.swift:1: // swift-tools-version: 6.4; Package.swift:52: swiftLanguageModes: [.v5]) (same in
  [email protected]:52 through [email protected]:52);
  project_validator/ecosystems/swift.py:227-231: COMPLETE_CONCURRENCY = pattern(... r"swift-tools-version:\s*6|\bswiftLanguageModes?\s*:\s*\[\s*\.v6|...")
  matches the tools version alone.
• repro: Package.swift with // swift-tools-version: 6.0 and swiftLanguageModes: [.v5]; the pattern should
  yield to an explicit .v5 mode (and to .swiftLanguageMode(.v5) per target).
• confidence: high

vapor/vapor / warnings-as-errors

• kind: FALSE_POSITIVE
• actual: PASS: Swift: warnings are treated as errors with -warnings-as-errors
• expected: FAIL: the only match is a commented-out line; nothing in CI, Package.swift or the sub-packages treats
  warnings as errors (grep -rn "warnings-as-errors" over the checkout returns nothing).
• evidence: Package.swift:262: // .treatAllWarnings(as: .error),; --answers output:
  "found": {"-warnings-as-errors": ["Package.swift"]}; project_validator/ecosystems/swift.py:247-255 searches
  the raw text with \btreatAllWarnings\s*\(\s*as:\s*\.error\b. The PASS message also names a flag
  (-warnings-as-errors) the project never uses: the pattern's name, not the match.
• repro: a Package.swift whose swiftSettings contains only // .treatAllWarnings(as: .error).
• confidence: high

realm/SwiftLint / warnings-as-errors

• kind: FALSE_POSITIVE
• actual: PASS: Swift: warnings are treated as errors with -warnings-as-errors, credited to
  CI (.github/actions/bazel-linux/action.yml)
• expected: the status happens to be right (Bazel copts carry the flag) but the credited evidence is a patch
  file name that removes the flag; the real setting lives in a Bazel file the validator does not read, so on a
  project without bazel/copts.bzl the same line would be a plain false pass.
• evidence: .github/actions/bazel-linux/action.yml:24: git apply --ignore-whitespace .bcr/patches/no-warnings-as-errors.patch;
  bazel/copts.bzl:5: "-warnings-as-errors",; .bcr/patches/no-warnings-as-errors.patch:9:
  - "-warnings-as-errors",; --answers: "found": {"-warnings-as-errors": ["CI (.github/actions/bazel-linux/action.yml)"]};
  project_validator/ecosystems/swift.py:250: r"-warnings-as-errors\b|..." has no left-hand boundary.
• repro: a workflow step run: git apply no-warnings-as-errors.patch and a Package.swift without the setting.
• confidence: high

Alamofire/Alamofire (and all Swift projects) / ci-build-types vs sanitizers

• kind: MESSAGE
• actual: [FAIL] ci-build-types: 17 of 17 OS/Swift toolchain combination(s) do not build Debug and Release, each with and without sanitizers (linux / 6.0: missing Debug + sanitizers, Release, Release + sanitizers) while
  [SKIP] sanitizers: not applicable to JavaScript, Ruby, Swift. Same pair in every Swift project.
• expected: one position: either Swift sanitizer builds (swift build --sanitize=address|thread, -Xswiftc -sanitize=thread) are recognised and asked for by both checks, or ci-build-types does not demand "+ sanitizers"
  for a language whose sanitizers check is skipped. SwiftLint actually runs TSan tests, which neither check sees.
• evidence: SwiftLint Makefile:15: TSAN_SWIFT_BUILD_FLAGS=-Xswiftc -sanitize=thread; Makefile:44-45:
  test_tsan: / swift build --build-tests $(TSAN_SWIFT_BUILD_FLAGS); .buildkite/pipeline.yml:25:
  - make bazel_test_tsan; docs/ecosystems/swift.md "ci-build-types: ... each with and without sanitizers" but no
  sanitizers section.
• repro: any Package.swift project with a workflow running swift test -c debug and swift test -c release.
• confidence: medium

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt