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 摘要。