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

Offen
  • Stimmt etwas nicht?
#244 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python, swift
Bereich
tooling

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.