CC & REPL: restore :type, :doc, and tab completions

[bracevac]

Fix #25465
Fix #25790

Problem

In a REPL session with capture checking enabled:

• :type and :doc crash (ArrayIndexOutOfBoundsException) instead of reporting a normal error
• tab completion fails for ordinary lookups such as x.toStr
• REPL wrapper vals spuriously trip the explicit-type check for fields that capture a root capability

scala> import language.experimental.captureChecking
scala> trait Foo
scala> :type Foo
java.lang.ArrayIndexOutOfBoundsException: ...

Root cause

ReplCompiler.typeCheck runs compileUnits with -Ystop-after:typer. Until now, that truncated the shared phase tables — later REPL helpers consulting CC phase ids would blow up. Tab completion separately re-entered Predef's wrap*Array implicits during scope scanning. And the explicit-type check fired on synthetic REPL wrapper fields that the user can never see.

Fix

1. Decouple -Ystop-after from phase registration. fusePhases no longer takes a stopAfterPhases parameter; the registered phase plan is always full and phase ids stay stable. runPhases honors stopAfter at execution time and stops after the phase group containing the named phase. The setting description and the inspection docs are updated to reflect that group-level granularity.
2. REPL typeOfWithCC runs the full pipeline up to and including cc, so :type shows capture annotations.
3. Exempt REPL wrapper fields from the explicit-type check for fields capturing root capabilities — those wrappers are invisible to the user.
4. Suppress TypeError from extensionCompletions in the REPL so cycles in Predef's wrap*Array don't kill tab completion.
5. Printer: empty capture sets on function arrows (->{}) print as ->; trivial empty lower bounds on capture-set type parameters (>: {}) are elided.

Tests

• CC-enabled tab completion (#25790)
• :type on CC examples (Logger / File capabilities, .rd, classifiers, function captures, eta-expanded methods)
• REPL wrapper inference / explicit-type handling for capability-typed vals
• Updated sep-curried-par.check for the ->{} → -> printer change

How much have you relied on LLM-based tools in this contribution?

Lots

How was the solution tested?

• Full REPL test suite (sbt scala3-repl/test) passes
• Manual REPL testing with import language.experimental.captureChecking, then :type, :doc, and tab-completion checks

[bracevac]

While this is strictly better now, we still have some usability warts, which I suspect are due to the way the REPL wraps lines under the hood:

Type inference is broken

scala> val l = Logger(y)
-- Error: ----------------------------------------------------------------------
1 |val l = Logger(y)
  |     ^
  |value l needs an explicit type because it captures a root capability in its type Logger{val f: File^{y}}^{any, y}.
  |Fields capturing a root capability need to be given an explicit type unless the capability is already
  |subsumed by the computed capability of the enclosing class.
  |
  |where:    any is a root capability classified as SharedCapability in the type of value l
1 error found

And say we have managed to define l, then the :type command also complains:

scala> val l:Logger^{caps.any,y} = Logger(y)
val l: Logger^{any, y} = Logger@52bf434b

scala> :type l
-- Error: ----------------------------------------------------------------------
1 |l
  |^
  |value res0 needs an explicit type because it captures a root capability in its type Logger{val f: File^}^{l}.
  |Fields capturing a root capability need to be given an explicit type unless the capability is already
  |subsumed by the computed capability of the enclosing class.
  |
  |where:    ^ refers to a root capability classified as SharedCapability in the type of value f

Fairly sure this is an artifact of how we treat classes/objects and the REPL wrapping lines in them.

Edit: After rebasing with the latest CC changes, these issues seem to have been resolved. However, there's still issues around type inference, e.g.,

scala> import language.experimental.captureChecking

scala> import caps.*

scala> class File extends SharedCapability

scala> val x = File()
-- Error: ----------------------------------------------------------------------
1 |val x = File()
  |     ^
  |value x needs an explicit type because it captures a root capability in its type File^.
  |Fields capturing a root capability need to be given an explicit type unless the capability is already
  |subsumed by the computed capability of the enclosing class.
  |
  |where:    ^ refers to a root capability classified as SharedCapability in the type of value x
1 error found

scala> :type File()
-- Error: ----------------------------------------------------------------------
1 |File()
  |^
  |value res0 needs an explicit type because it captures a root capability in its type File^.
  |Fields capturing a root capability need to be given an explicit type unless the capability is already
  |subsumed by the computed capability of the enclosing class.
  |
  |where:    ^ refers to a root capability classified as SharedCapability in the type of value res0
1 error found

These are a bit too surprising for users IMO and should actually work.

[bracevac]

Edit: After rebasing with the latest CC changes, these issues seem to have been resolved. However, there's still issues around type inference, e.g.,

// [...]
scala> val x = File()
// [...]
scala> :type File()

These work now.

[noti0na1]

Maybe it's easier to write repl tests in repl/test-resources/repl/?

[bracevac]

The scripted test format doesn't work for our tests because:

1. :type and :doc commands get parsed as Scala code, not REPL commands
2. val output includes non-deterministic object addresses
3. FileDiff.matches is strict equality — no wildcards

[bracevac]

Here's something that's outside the scope of this PR:

The :type command gives hilariously bad types for eta-expanded methods.

scala> def foo[X](id: X): X = id
def foo[X](id: X): X

scala> :type foo
Any -> Any

Involving captures:

// assume val l = Logger(f) in context
scala> def convert2(xs: List[Unit]): List[Unit] = { println(l); xs.map(_ => ()) }
def convert2(xs: List[Unit]): List[Unit]

scala> :type convert2
List[Unit] ->{rs$line$16} List[Unit]

The capture set will mention the synthetic wrapper object of l, not l itself.

I also discovered a genuine bug (#25830) in the type inference of polymorphic lambdas:

scala> val convert22 = { [C^] => (xs: List[File^{C}]) =>  println(l); xs.map(_ => ()) }
val convert22: [C^] => (xs: List[File^{}]) ->{l} List[Unit] = Lambda$2370/0x000000c8015fefc8@6ae6a1ce

It should be (xs: List[File^{C}).

[noti0na1]

This PR passes all tests in tacit as well.

[bracevac]

@odersky the changes to SymDenotations break lots of things in the CI. Just checking for existence of the denotation is futile, as it's already too late at that point.
Maybe the previous fix bc808c1 (which is local to the REPL) is better?

[bracevac]

@odersky as per our discussion, I reverted to the simple strategy of suppressing the cycle error from extensionCompletions in the REPL. From my end, this is ready now.

[bracevac]

For posterity: with CC enabled, the tab completion can print weird cyclicity errors from resolving extension methods. Those errors relate to the various wrap*Array implicits in Predef. Those seem to involve an unexpected ClassCastException when resolving package objects in SymDenotations.

Several things were tried, including unlinking cc symdenotation transformers, and recovering the denotation state on such unexpected errors. But those were deemed too risky.

In the end, we decided to just gracefully recover in the REPL when the completion of extension methods produces such an error.

[odersky]

Otherwise LGTM

[odersky]

That's a bit pedestrian. I think it would overall be simpler if runPhases stopped after stopAfter and the phase state did not depend on Ystop-after. The we would not need to save and restore phase state.

[odersky]

I don't think we need the truncatedAt functionality. Let's just run the full megaphase. That simplifies things.