Scala: `scalafixCheck` alias, sbt-typelevel/sbt-tpolecat warning sets, `++${{ matrix.scala }}` cross versions read as "Scala default", JDK from a fallback expression, embedded H2 Flyway scripts

未關閉
#274 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
20/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
github-actions, java, python, scala
領域
ci-cd, devtools

研究方向

The Scala checks live in ecosystems/scala.py; the regexes at about lines 36, 294, 300, 383 and 395 (SBT_FILES, _TPOLECAT, FATAL_WARNINGS, _SCALA_VERSION and the ++ pattern) are where the misreadings come from. Run the repro cases in scratchpad/repro (s1, j1, j2, j3) to see each wrong verdict. Done means each repro gives the expected PASS or count without changing the other Scala and Java cases. The report bundles six separate problems, so pick one, such as the ++ ${{ matrix.scala }} pattern, and start there.

由索引模型根據 Issue 內容生成。

描述

metals: static-analysis FAIL "scalafix configured but does not run" though the "Scalafix and docs" job runs scalafixCheck (an alias for scalafix --check); scalafmt: compiler-warnings/warnings-as-errors FAIL though the build sets -Wunused:all and fatal warnings for every Scala version; cats: "no scalac warning options" though sbt-typelevel bundles sbt-tpolecat (the docs credit it); http4s is credited -Werror/-deprecation from text that is not a compiler setting. cats/http4s: ++${{ matrix.scala }} → every job "Scala default", 3 combinations instead of 9 (the ++ handling of #146 does not cover a matrix variable); scalafmt's post-jvm matrix gives "JDK default" from a fallback expression. metals' 8 Flyway scripts are for its embedded per-workspace H2 cache, not a live database (migration-safety WARN).

Evidence from the corpus audit

scalameta/metals / static-analysis
  • kind: FALSE_NEGATIVE
  • actual: [FAIL] static-analysis: ... Scala: scalafix is configured (.scalafix.conf) but does not run
  • expected: PASS: the "Scalafix and docs" job runs scalafixCheck, an alias for scalafix --check on both configurations.
  • evidence: build.sbt:87: addCommandAlias("scalafixCheck", "; scalafix --check ; Test/scalafix --check");
    .github/workflows/ci.yml:173: command: sbt 'scalafixCheck; docs/run; docs/docusaurusCreateSite'.
    sbt command aliases defined in the build are not resolved (scalafmt's sbt test-jvm-2_12 etc. are aliases too).
  • repro: scratchpad/repro/s1 (build.sbt with the alias, .scalafix.conf, run: sbt scalafixCheck) -> WARN "does not run".
  • confidence: high
scalameta/scalafmt / compiler-warnings, warnings-as-errors
  • kind: FALSE_NEGATIVE
  • actual: Scala: no scalac warning options found; enable at least -deprecation, -feature, -Xlint or -Wunused; Scala: warnings are not treated as errors in the build or CI configuration
  • expected: PASS for both: the build sets -Wunused:all and fatal warnings for every Scala version.
  • evidence: project/Extensions.scala:73: if (isScala212.value) opts ++= Seq("-Xfatal-warnings", "-deprecation:false"),
    :74: else opts += "-Wconf:any:error,cat=deprecation:silent", :76: if (isScala3.value) opts += "-Wunused:all",
    :91: Compile / compile / scalacOptions ++= scalacJvmOptions.value.
    Source: ecosystems/scala.py:36: SBT_FILES = ("*.sbt",) - the project/*.scala build definition is never read.
  • repro: build.sbt + project/Opts.scala containing scalacOptions ++= Seq("-Werror", "-Wunused:all").
  • confidence: high
http4s/http4s / warnings-as-errors, compiler-warnings
  • kind: FALSE_POSITIVE
  • actual: Scala: warnings are treated as errors with -Werror; Scala: found -deprecation
  • expected: the status may be right (sbt-typelevel makes warnings fatal in CI by default), but the cited evidence is not a compiler setting.
  • evidence: -Xfatal-warnings occurs only inside a string literal, build.sbt:1093-1094: lazy val enableFatalWarnings: String = / """set ThisBuild / scalacOptions += "-Xfatal-warnings""""
    (an sbt command text for an alias; build.sbt:1097 is the matching disableFatalWarnings). -deprecation occurs only in
    project/build.sbt:1-3: scalacOptions := Seq( / "-deprecation" - the meta-build's options for compiling the build
    definition, not the product. grep -rn Werror --exclude-dir=.git finds nothing else. Matching is a text regex over *.sbt
    (scala.py:300: FATAL_WARNINGS = _setting("-Werror", r"-Werror\b|-Xfatal-warnings\b")).
  • repro: build.sbt containing only val s = """set scalacOptions += "-Werror"""" -> warnings-as-errors PASS.
  • confidence: medium
typelevel/cats / compiler-warnings
  • kind: FALSE_NEGATIVE
  • actual: Scala: no scalac warning options found; enable at least -deprecation, -feature, -Xlint or -Wunused
  • expected: PASS: sbt-typelevel bundles sbt-tpolecat, which sets the whole strict set (the docs credit sbt-tpolecat).
  • evidence: project/plugins.sbt:2: addSbtPlugin("org.typelevel" % "sbt-typelevel" % sbtTypelevelVersion).
    Source: ecosystems/scala.py:294: _TPOLECAT = r"\bsbt-tpolecat\b|\btpolecat(?:ScalacOptions|DefaultOptionsMode|OptionsMode)\b" - no sbt-typelevel.
    Note the cats warnings-as-errors FAIL is correct: build.sbt:24: ThisBuild / tlFatalWarnings := false.
  • repro: project/plugins.sbt with sbt-typelevel and no explicit scalacOptions.
  • confidence: medium (the bundling is a fact about the plugin, not visible in the checkout)
typelevel/cats, http4s/http4s / platform-matrix (Scala versions from ++)
  • kind: FALSE_NEGATIVE
  • actual: Scala: CI covers 1 OS(es) (linux), 3 JDK or Scala version(s) (JDK 17, JDK 21, JDK 8), 3 combination(s); .map.json shows "Scala default" for every job
  • expected: 3 Scala versions on each JDK (JDK 8 / Scala 2.12, ...), 9 combinations; the OS verdict stays FAIL but the count and the map are wrong.
  • evidence: cats .github/workflows/ci.yml:31: scala: [2.12, 2.13, 3], :117: run: sbt 'project ${{ matrix.project }}' '++ ${{ matrix.scala }}' test;
    http4s ci.yml:32: scala: [3, 2.12, 2.13], :121 (same form). sbt-typelevel generates exactly this '++ ${{ matrix.scala }}'
    word, so it is the norm in the Typelevel ecosystem. Source: scala.py:383: _SCALA_VERSION = r"(\d+\.\d+\.\d+(?:-\w+)?)"
    (requires x.y.z; sbt accepts binary versions) and :395: rf"\+\+{_SCALA_VERSION}" (no space allowed).
  • repro: scratchpad/repro/j3 (scala: [2.12, 2.13, 3], run: sbt '++ ${{ matrix.scala }}' test) -> every job Scala default.
  • confidence: high
scalameta/scalafmt / platform-matrix (JDK from a fallback expression)
  • kind: UNREAD
  • actual: Scala: ... 4 JDK or Scala version(s) (JDK 17, JDK 21, JDK default, default); .map.json: post-jvm (ubuntu-24.04, 21) ... ['JDK default', ...]
  • expected: JDK 17/JDK 21 for the post-jvm matrix and JDK 17 for the w1..w5 workers.
  • evidence: .github/workflows/ci.yml:55: java-version: ${{ matrix.java || '17' }} (a YAML anchor &jdk reused by every job);
    :39: java: [ '17', '21' ]. Only the native-image jobs (:229: java-version: '21') resolve.
  • repro: scratchpad/repro/j1 (java-version: ${{ matrix.java || '17' }}) -> JDK default; j2 (${{ matrix.java }}) -> JDK 17, JDK 21.
  • confidence: high
scalameta/metals / migration-safety
  • kind: MESSAGE
  • actual: [WARN] migration-safety: 8 migration files, but no CI configuration checks them for unsafe changes
  • expected: not judged, or worded differently: these are Flyway scripts for Metals' embedded, per-workspace H2 cache, not a live shared database.
  • evidence: metals/src/main/resources/db/migration/V1__Create_tables.sql:1-3: -- The relationship between library dependency sources under .metals/readonly/** ...; metals/src/main/resources/shared-db/migration/V1__Jar_type_hierarchy.sql.
  • repro: unclear (needs a notion of "embedded database")
  • confidence: low

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

主要語言
Python
星號
4
分支
1
平均合併
10 小時 41 分鐘
30 天內合併 PR
79

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

cpp-best-practices/project_validator 的其他 Issue

查看 cpp-best-practices/project_validator 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。