[prabhu]

Running scalasem over a fresh sbt 2.0.10 build of atom (Scala 3.10.0) produced facts for only 4 of its 24 main sources, with an unreadable-tasty count of 21. The cause was the module classpath, not the TASTy reader. sbt 2 prints dependency paths in a virtual form, and a dependency installed with publishLocal, which is how atom picks up chen, comes out as ${IVY_HOME}/local/io.appthreat/.... scalasem only expanded ${CSR_CACHE}, ${OUT}, ${BASE} and ${WORKSPACE}, so every chen jar stayed as a literal ${IVY_HOME} path and was dropped from the inspector classpath. The compiler then reported the chen symbols as undefined, the inspector stopped with a MatchError on NoSymbol, and each batch that referenced chen came back with nothing but a diagnostic until the retry budget ran out.

expandVirtualPaths now expands every root the sbt 2 file converter maps, which per sbt.internal.Load in sbt 2.0.10 are OUT, BASE, SBT_BOOT, IVY_HOME and JAVA_HOME alongside the Coursier cache. The Ivy home and boot directory follow the sbt launcher: sbt.ivy.home and sbt.boot.directory (or sbt.global.base) when set through JAVA_OPTS, SBT_OPTS, .jvmopts or .sbtopts, and otherwise ~/.ivy2 and ~/.sbt/boot. The batching and retry budget are unchanged.

Over atom at b66128a, files with facts went from 4 to 24 of 24, calls from 321 to 8223 and references from 948 to 16003, and the unreadable-tasty diagnostic is gone. The unresolved-symbols count went from 11 to 115 because far more code is now walked; the compiler prints no errors for those, and chen shows a similar rate. Over chen at 3b1595a1 the report is unchanged: 525 files and the same counts and diagnostics before and after. The new test in scalasem-engine.js fails on main and passes here. npm test and npm run test:scala pass and Prettier reports no changes.

The version is bumped to 1.10.6.