Scala: never throw from parseInputs and self-heal compiler core libraries

[knutwannheden]

Motivation

ScalaParser.parseInputs() could throw instead of producing per-file ParseError source files, which kills entire builds in downstream tools (observed on apache/flink, where a resource build step died mid-build). Two related problems:

1. parseInputs() could throw. Batch compilation (compilerContext.compileAll(...)) ran outside the per-input try/catch, so any exception from it propagated to the caller and failed the whole parse stream. Inside the bridge, the phase-1 parse loop also had no per-entry handling, so one file that failed to parse aborted the entire batch. Other parsers (e.g. JavaParser, KotlinParser) yield a ParseError for the failing file and keep going.

2. Parsing A with B types threw MissingCoreLibraryException without the Scala stdlib on the classpath. Parsing a self-type like class Service { self: Logging with Config => } with an empty classpath inside a fat-jar application threw dotty.tools.dotc.MissingCoreLibraryException: Could not find package scala from compiler core libraries (withTypeRest → untpd.makeAndType → Definitions.andType → Denotations.staticRef). Dotty's Run construction needs the Scala stdlib to initialize Definitions; when the caller's classpath lacks it — or overrides dotty's default lookup, as a fat jar does — the bridge fell back to a bare context where with types "fail loudly". This didn't reproduce in the test JVM because dotty finds the stdlib via the JVM classpath there.

Summary

• ScalaParser.parseInputs() wraps batch compilation in a catch-all; on failure it reports via ctx.getOnError() and degrades to the existing per-file fallback, where each input independently yields a real tree or a ParseError.
• ScalaCompilerBridge.compileAll catches per-entry parse failures in its phase-1 loop and omits the entry, so the caller's single-file fallback surfaces a ParseError for that file only.
• When Run construction fails, the bridge retries it with the compiler's own core library jars appended (located via ProtectionDomain, which works inside a fat jar). The retry needs an entirely new compiler context: the failed attempt has already cached the ContextBase's platform classpath, so updating the setting on a fresh of the same base has no effect.
• The healed Run is used for parsing only — no type attribution. Narrow-classpath callers like ScalaTemplate intentionally avoid type resolution of user types; they only need the initialized ContextBase so with types parse.
• Extracted configuredContext(...) in the bridge to share compiler context setup between compileAll and parse.

Test plan

• New test: one unparseable input (stack-overflowing nesting) among good inputs → good inputs parse, bad one comes back as ParseError (previously the error killed the whole stream)
• New test: a batch failure (source whose first read throws) degrades to per-file parsing instead of throwing out of parseInputs
• New test: with self-type parses to a real S.CompilationUnit with a classpath containing only a non-Scala jar, which overrides dotty's default stdlib lookup to simulate the fat-jar environment (previously MissingCoreLibraryException)
• New test: precondition check that the same self-type parses with the full runtime classpath
• ./gradlew :rewrite-scala:check passes (full module test suite, license check)

[greg-at-moderne]

Great improvement.