Fix missing docstrings in the native-image binary

[rochala]

The bug

No Scala 3 artifact has ever produced a docstring from a released binary, and it failed silently.

DocstringExtractor read the Scala version from dotty.tools.dotc.config.Properties.versionNumberString, which reads compiler.properties out of the compiler jar. native-image does not embed that resource, so the version came back empty and the stdlib fetch asked coursier for a versionless coordinate:

not found: https://repo1.maven.org/maven2/.../scala3-library_3//scala3-library_3-.pom

The fetch failed, the TASTy inspector never ran, and the old catch case _: Exception swallowed it.

Reproduced against the published 0.1.0-M10 native binary:

$ cellar get-external org.typelevel:cats-effect_3:3.5.4 cats.effect.IO   # released binary
## cats.effect.IO
class IO[+A] extends IOPlatform[A]      # no docstring

$ ./mill cli.run get-external ... cats.effect.IO                         # JVM build
A pure abstraction representing the intention to perform a side effect...

The fix

Read the version from the stdlib rather than the compiler:

val scalaVersion = scala.util.Properties.versionNumberString

Two things make this the right source. Since 3.8 the standard library ships as org.scala-lang:scala-library at the Scala 3 version — scala3-library_3:3.8.4 is now a thin shim depending on scala-library:3.8.4, and that jar's library.properties carries version.number=3.8.4. So this yields a Scala 3 version, not the 2.13.x it would have on older Scala 3.

And unlike compiler.properties, native-image does embed library.properties. That is verifiable in the shipped M10 binary, which predates this change:

$ strings -a $(readlink -f $(which cellar)) | grep -E 'version.number=|^library.properties$'
library.properties
version.number=3.8.1          # M10's Scala version
$ strings -a ... | grep -x compiler.properties
                              # absent — this is the actual bug

Note this requires the 3.8+ stdlib; a drop below 3.8 would silently return a 2.13 version again, so there is a comment at the call site saying so.

Verification

Rebuilt the native image: it embeds version.number=3.8.4, docstrings extract, and the TASTy inspector runs cleanly with no warnings at --debug. lib.test 372/372, cli.test 236/236.

This surfaced only because the recent --debug work (#127) made the failure visible — and specifically because of the fix to catch fatal errors inside the blocking thunk.

Note

The regression class here (JVM works, native-image silently differs) is invisible to the current test suite — nothing ever runs the built binary. Tracked separately in #133; not addressed here.

🤖 Generated with Claude Code