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

Aberta
  • Algo errado?
#244 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python, swift
Domínio
tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.