I'll take another look when my eyes are fresh, but some notes:

• I didn't fail outright on bad or missing "after", because "before erasure" seems fine in general (but then it should just say "after parser" explicitly)
• I was wondering why adding "after parser" to everything does not work: the distances work out the same, but the code for sorting at the same "level" checks for "incoming edge from previous level" (instead of "which phases at this level are runsRightAfter"), the anomaly was plugin between packageobjects and typer
• as lrytz noted, the existing "just make it follow parser" resulted in sorting by name of the "anchors" (namer is anchor of namer -> packageobjects -> typer)
• validate now checks reachable, which is not guaranteed by "after" given cycles; for edge cases "before parser" or cycles, this warns but should fail
• I tired of uncommenting the local debugging code
• the unit test uses a large phase set, so linear search of names is slow

appreciating the blue notation for updating a check file.

         typer   4  the meat and potatoes: type the trees
            C1   0  C1 tests phase assembly
            C2   0  C2 tests phase assembly
superaccessors   7  add super accessors in traits and nested classes

but -Vprint:5 works

crashes 2.13.14 creating the dot file

    override val runsRightAfter = None
    override val runsAfter = List("typer")
    override val runsBefore = List("typer")

Realized I don't need N plugins but one plugin with N components to test the permutations.

In Knuth, "boolean basics" says here's a table of operations, there are 16 of them. I was like what? so in addition to not assuming I know anything, I assume I know less than I thought I did.

Edit: well, this PR also throws for reporting.

error: scala.reflect.internal.FatalError: Phases form a cycle: typer -> superaccessors -> extmethods -> pickler -> refchecks -> patmat -> C2 -> typer

for

    override val runsRightAfter = Option("patmat")
    override val runsAfter = List("typer")
    override val runsBefore = List("typer")

where I think we don't want to ignore a before constraint that correctly names a phase but the constraint can't be satisfied. (The original ticket 8755 mentions this behavior of runsRightAfter.)

Naturally it also detects the other case

error: scala.reflect.internal.FatalError: Phases form a cycle: typer -> C4 -> typer

I think I already knew 2.13.14 scalac fails on these obvious constraints.

    override val runsRightAfter = None
    override val runsAfter = List("typer")
    override val runsBefore = List("erasure")

error: scala.reflect.internal.FatalError: Phase erasure can't follow explicitouter, created phase-order.dot

So we don't want to remain bug-compatible, but merely convenience-compatible for Scaladoc.

Worth adding that on linked ticket 7905 ten years ago, I'd already noticed that generating the phase graph file throws.

The OG also complains that before constraint is not sufficient. This PR accepts C7 with no after constraint (only before terminal) because it is reachable through C8. I'm about to change that and preserve that one bit of buggy behavior, because Lukas said to, and because it is easy to describe: a runs-after constraint is required. TODO that's incorrect, 2.13.14 has the same behavior; scaladoc says warning: dropping dependency on node with no phase object: patmat but does not drop the phase (which runs). Maybe I misunderstood Lukas's comment, as I haven't tried it out yet.

         typer   4  the meat and potatoes: type the trees
            C1   0  C1 tests phase assembly
            C8   0  C8 is before C7 which specifies no after
superaccessors   7  add super accessors in traits and nested classes
            C7   0  C7 tests phase assembly if only a before constraint
    extmethods   9  add extension methods for inline classes

I feel bad even suggesting this, but perhaps it would be better to revert the original PR entirely, in order not to be under time pressure, then try to land a revised version in 2.13.16.

@SethTisue I see your point, but it's just shaking out a few edge cases. That's not going to change by waiting.

I'll add the comprehensive test for review of all possible behaviors.

However, it does belie the current practice that "it doesn't matter if we merge PRs because nothing will get tested until the week before the release." "Cramming" is what makes Scala a so-called "academic language", I just realized.

I am the last to understand that scala-js exposes different components for scaladoc:

    if (global.isInstanceOf[doc.ScaladocGlobal]) {
      List[NscPluginComponent](PrepInteropComponent)
    } else {
      List[NscPluginComponent](PreTyperComponentComponent, PrepInteropComponent,
          ExplicitInnerJSComponent, ExplicitLocalJSComponent, GenCodeComponent)
    }

so there is no mysterious convenience in trimming them. I haven't refreshed my memory about backend phases yet.

It's a good counterargument to observe that the only additional plugins, not in the community build, that are likely to get tested with this, and only at release time, are Scala.js, Scala Native, and my own Fortify plugin.

I'm just going to finish Jane the Virgin before I push another commit, but I realize Scala 2 is basically EOL so you have your priorities, it's really no skin off my nose. Edit: that was followed by a Charmed marathon.

I am the last to understand that scala-js exposes different components for scaladoc:

Huh. I had completely forgotten about that. Sorry for leading the instigation in the wrong direction. 🙁

Celebrating 11 yrs since scala-js plugin.

-Werror doesn't work because the warnings are issued early, then Run.compileUnits resets the reporter (and its warning count)

Threw in a -Werror check, similar to the check at compileSources. "Something went wrong so summarize now."

I did not yet add the test for "two components are dropped".

I intended to comment in the minor refactor in PhaseAssembly.traverse that filtering for distance >= 0 eliminates the unreachable (dropped) component(s).

I could polish more, as there are a few spots where I can't see my face.

@som-snytt in the interest of moving 2.13.15 ahead I'd like to focus on what we need for that, so I submitted a minimal diff (#10858). Can we go ahead with this for now?

The remaining changes from my PR to this one: https://github.com/lrytz/scala/compare/pr10856light...lrytz:scala:pr10856?expand=1

What we can address after 2.13.15

• detect duplicate phase names. weirdly, SubComponent overrides equals to compare the phase name, so phases with the same name don't end up in Global.phasesSet
• -Werror for phase assembly warnings

Can you summarize what else is in the remaining diff? Performance improvements, debug logging, code cleanups.

On duplicate names, I mention somewhere that Scala 3 uses a fixed "spine" of phases which supports name duplication. One could explore how options should work that rely on names. Scala 3 options don't use phase id.

Also phase replacement was potentially a feature.