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

Ouverte
  • Quelque chose ne va pas ?
#244 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python, swift
Domaine
tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.