This opens many new ways that the compiler could crash. Until now, all phases could assume that the previous phases ran without error, and that, therefore, the program respected all invariants checked by previous phases. For example, all phases after typer assume that there is no erroneous type in trees.

If you allow phases to run after another one had errors, you break this. This could lead to many new compiler crashes.

Are you against it or are you saying this needs some amends to set expectations appropriately?

I'm against it. This breaks invariants that the compiler relies on not to crash. Unless there is an audit of all phases to identify and fix all places where they rely on those invariants, this change basically creates new crashes by design. And that's even without counting compiler plugins.

Try and enable this flag with "until cleanup" on all neg tests: I'm sure you'll notice how bad this is.

I'm sure you'll notice how bad this is.

How bad is it? A -Y flag that may cause new compiler crashes doesn't concern me, provided it doesn't do something destructive like delete the source files.

I considered restricting to -Yrun-to-refchecks, which may be the only use case.

Conceivably, someone may like to ignore some unrelated error to exercise a plugin which runs later.

I don't have a strong argument for that use case; a plugin author might chime in to say they needed that once.

The argument in favor is that -Y has a low bar. There have always been -Y options that are crashy or unstable.

The counter-argument is that -Wconf is supposed to let you ignore an error. Is it convenient enough for the use case, "What would refchecks say?" -Wwrs.

Drafting for improved ergonomics and sjrd-friendliness. For a single run, enabling refchecks is viable even with potential for crash, but not in resident or incremental case. As noted above, when would you even think to enable a flag? If compiler doesn't do refchecks safely always to add more info to error case, then there isn't much point.

I'm also against this feature in its generality.

What I could imagine is a way to run only refchecks (possibly with some of its checks / transformations disabled) after an erroneous typer phase. Running other phases doesn't make sense, they don't report any errors (except maybe some of the form "this is OK Scala code but sadly can't be represented in classfiles, sorry").

@sjrd what do you think about that?

I just noticed a semantically relevant dotty error obscured by a subsequent error. (As happens.) I want to see the "previous" error. Here, I want to run short-circuited checks and see those "subsequent" errors. It's like a Stephen Hawking thing where peering into the past is symmetrical to peering into the future.

@lrytz That is clearly less bad than the general feature. Did you mean to run only refchecks (and not other phases between typer and refchecks) or everything until refchecks?

• Only refchecks could report spurious errors for codebases with (arguably bad?) compiler plugins inserting a phase between typer and refchecks that "fixes" things that would otherwise be reported by refchecks. It's not entirely unheard of: I think that Mill has such a phase to slap override automatically for you.
• Everything until refchecks could have other consequences, this time with a larger set of compiler plugins: every phase added by a compiler plugin between typer and refchecks might crash on unexpected inputs.

Now, if we audit refchecks well enough, and test it well enough on inputs that don't pass typer, then at least we could limit the new-kinds-of-crashes area to such compiler plugins.

Testing it well enough, IMO, is at the very least testing that refchecks does not crash on any of the existing neg tests.

Did you mean to run only refchecks

Yes - but i see your point about plugins.

Summary, a tool that runs only "checks" after failing typer and probably only to refchecks checks.