Add unsafe RawPresentationCompiler implementation #24133

rochala · 2025-10-03T22:25:35Z

RawPresentationCompiler is a direct, unsafe way to access presentation compiler interface provided in
scalameta/metals#7841

It is up to the consumer to guarantee thread safety and sequential request processing.
This solves many issues with the current PresentationCompiler interface but most important are:

We now have control where and how each presentation compiler method is run. Before it was always run on a SingleThreadExecutor created by the PresentationCompiler. The original behavior will stay with the standard ScalaPresentationCompiler interface. (There is another PR that refactors that part),
If there was bug in scheduler all versions were affected,

On top of that this PR implements all things that will work out of the box:

Diagnostic provider - trivial implementation, previously not possible to LIFO task used by Scala3CompilerAccess. Will be super useful e.g for Scastie which will become a consumer of this new raw API.
InteractiveDriver compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe ScalaPresentationCompiler and CancelTokens. Here we can omit the cancel token support for now, because we would check for Thread.interrupted() along the cancelToken.isCancelled anyway, and we can now easily interrupt it from e.g IO.interruptible

Those changes were adapted from my other PR's that required adjustment of Scala3CompilerAccess but I don't think it is ready / I'm not happy with current state of that refactor.

In the future we should think of replacing the implementation of ScalaPresentationCompiler to use RawPresentationCompiler as underlying impl and just call it in safe way.

The implementation was tested on the actual LSP server and it works fine.

…iver will now check for Thread.isInterrupted cancellation

rochala · 2025-10-03T22:26:36Z

presentation-compiler/src/main/dotty/tools/pc/PcInlayHintsProvider.scala

-              LabelPart(": ") :: toLabelParts(tpe, pos),
-              InlayHintKind.Type,
-            )
-            .addDefinition(adjustedPos.start)


It was removed out of sudden in Scala 2 presentation compiler, I believe it is no longer necessary as we're deduplicating inlay hints during add

I think it wasn't actually doing anything anymore

rochala · 2025-10-03T22:27:06Z

presentation-compiler/test/dotty/tools/pc/tests/inlayHints/InlayHintsSuite.scala

         |
         |def test/*: (path : String<<java/lang/String#>>, num : Int<<scala/Int#>>, line : Int<<scala/Int#>>)*/ =
-         |  hello ++/*[Tuple1<<scala/Tuple1#>>["line"], Tuple1<<scala/Tuple1#>>[Int<<scala/Int#>>]]*/ (line = 1)/*(using refl<<scala/`<:<`.refl().>>)*//*[Tuple1<<scala/Tuple1#>>[Int<<scala/Int#>>]]*/
+         |  hello ++/*[Tuple1<<scala/Tuple1#>>["line"], Tuple1<<scala/Tuple1#>>[Int<<scala/Int#>>]]*/ (line = 1)/*[Tuple1<<scala/Tuple1#>>[Int<<scala/Int#>>]]*//*(using refl<<scala/`<:<`.refl().>>)*/


Caused by mtags version bump

KacperFKorban

Looks good to me. (Just "Comment", since I don't feel "in the loop" enough to understand the context of these changes)

KacperFKorban · 2025-10-06T09:43:14Z

presentation-compiler/src/main/dotty/tools/pc/PcInlayHintsProvider.scala

    }
-    
+
    tree match


TLDR: I think that it's fine to patch only the necessary changes for now, but this should probably be refactored (similarly as Scala 2 code) soon-ish.

The refactor in the Scala 2 PC was meant to allow for more than one "case" to be executed here. This isn't a problem yet, since scalameta/metals#7815 hasn't been ported yet. Though one could make an argument that this problem appeared before and was "hacked" my merging implementations for two inlay hint types.
The idea behind the refactor is:

We move the logic from the branches in this match into private methods on appropriate Inlay-Hint-providing-objects.

Afterwards, this method is simplified to a foldLeft through all the cases.

Every Inlay-Hint-providing-objects returns its inlay hints in separation, and we merge them together for every tree.

Afterwards, they can be deduplicated (right now only for InferredType) – this separates generation and deduplication.

I think that a similar refactor should be done here as well, though it maybe shouldn't be part of this PR.

presentation-compiler/src/main/dotty/tools/pc/RawScalaPresentationCompiler.scala

project/Build.scala

presentation-compiler/src/main/dotty/tools/pc/CachingDriver.scala

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala

presentation-compiler/src/main/dotty/tools/pc/RawScalaPresentationCompiler.scala

tgodzik · 2025-10-08T11:13:19Z

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala

+class DiagnosticProvider(driver: InteractiveDriver, params: VirtualFileParams):
+
+  def diagnostics(): List[lsp4j.Diagnostic] =
+    val diags = driver.run(params.uri().nn, params.text().nn)


We should check if diagnotics are expected via params.shouldReturnDiagnostics()

I added it recently, will be available in the new metals

Can you tell me the scenario in which you don't want to return diags ?

LSP always sends request after keypress in following order:
didChange -> completion -> inlayHints

It will be compiled by completion or inlay hints anyway so it doesn't matter, and getting diagnostics is a free operation in terms of computations.

I was thinking of cases where people would want to switch between the two modes.

Ok, I see it, it would be very easy to control this on lsp level though but yeah. We can add it for simplicity.

I don't see this param to be accessible

project/Build.scala

tgodzik

Great work, some minor last comments, but we should be good to include this in 3.8.0

project/Build.scala

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala

tgodzik · 2025-10-22T09:01:06Z

Looks like DiagnosticProviderSuite is failing, might just be on windows

rochala · 2025-10-22T09:01:59Z

Looks like DiagnosticProviderSuite is failing, might just be on windows

I'm fixing it, it will fail everywhere because I didn't override shouldReturnDiags in tests

tgodzik

LGTM!

`RawPresentationCompiler` is a direct, unsafe way to access presentation compiler interface provided in scalameta/metals#7841 It is up to the consumer to guarantee thread safety and sequential request processing. This solves many issues with the current `PresentationCompiler` interface but most important are: - We now have control where and how each presentation compiler method is run. Before it was always run on a `SingleThreadExecutor` created by the `PresentationCompiler`. The original behavior will stay with the standard `ScalaPresentationCompiler` interface. (There is another PR that refactors that part), - If there was bug in scheduler all versions were affected, On top of that this PR implements all things that will work out of the box: - Diagnostic provider - trivial implementation, previously not possible to LIFO task used by `Scala3CompilerAccess`. Will be super useful e.g for Scastie which will become a consumer of this new raw API. - `InteractiveDriver` compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe `ScalaPresentationCompiler` and `CancelTokens`. Here we can omit the cancel token support for now, because we would check for `Thread.interrupted()` along the `cancelToken.isCancelled` anyway, and we can now easily interrupt it from e.g `IO.interruptible` Those changes were adapted from my other PR's that required adjustment of `Scala3CompilerAccess` but I don't think it is ready / I'm not happy with current state of that refactor. In the future we should think of replacing the implementation of `ScalaPresentationCompiler` to use `RawPresentationCompiler` as underlying impl and just call it in safe way. The implementation was tested on the actual LSP server and it works fine.

`RawPresentationCompiler` is a direct, unsafe way to access presentation compiler interface provided in scalameta/metals#7841 It is up to the consumer to guarantee thread safety and sequential request processing. This solves many issues with the current `PresentationCompiler` interface but most important are: - We now have control where and how each presentation compiler method is run. Before it was always run on a `SingleThreadExecutor` created by the `PresentationCompiler`. The original behavior will stay with the standard `ScalaPresentationCompiler` interface. (There is another PR that refactors that part), - If there was bug in scheduler all versions were affected, On top of that this PR implements all things that will work out of the box: - Diagnostic provider - trivial implementation, previously not possible to LIFO task used by `Scala3CompilerAccess`. Will be super useful e.g for Scastie which will become a consumer of this new raw API. - `InteractiveDriver` compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe `ScalaPresentationCompiler` and `CancelTokens`. Here we can omit the cancel token support for now, because we would check for `Thread.interrupted()` along the `cancelToken.isCancelled` anyway, and we can now easily interrupt it from e.g `IO.interruptible` Those changes were adapted from my other PR's that required adjustment of `Scala3CompilerAccess` but I don't think it is ready / I'm not happy with current state of that refactor. In the future we should think of replacing the implementation of `ScalaPresentationCompiler` to use `RawPresentationCompiler` as underlying impl and just call it in safe way. The implementation was tested on the actual LSP server and it works fine. [Cherry-picked 582366c][modified]

`RawPresentationCompiler` is a direct, unsafe way to access presentation compiler interface provided in scalameta/metals#7841 It is up to the consumer to guarantee thread safety and sequential request processing. This solves many issues with the current `PresentationCompiler` interface but most important are: - We now have control where and how each presentation compiler method is run. Before it was always run on a `SingleThreadExecutor` created by the `PresentationCompiler`. The original behavior will stay with the standard `ScalaPresentationCompiler` interface. (There is another PR that refactors that part), - If there was bug in scheduler all versions were affected, On top of that this PR implements all things that will work out of the box: - Diagnostic provider - trivial implementation, previously not possible to LIFO task used by `Scala3CompilerAccess`. Will be super useful e.g for Scastie which will become a consumer of this new raw API. - `InteractiveDriver` compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe `ScalaPresentationCompiler` and `CancelTokens`. Here we can omit the cancel token support for now, because we would check for `Thread.interrupted()` along the `cancelToken.isCancelled` anyway, and we can now easily interrupt it from e.g `IO.interruptible` Those changes were adapted from my other PR's that required adjustment of `Scala3CompilerAccess` but I don't think it is ready / I'm not happy with current state of that refactor. In the future we should think of replacing the implementation of `ScalaPresentationCompiler` to use `RawPresentationCompiler` as underlying impl and just call it in safe way. The implementation was tested on the actual LSP server and it works fine.

`RawPresentationCompiler` is a direct, unsafe way to access presentation compiler interface provided in scalameta/metals#7841 It is up to the consumer to guarantee thread safety and sequential request processing. This solves many issues with the current `PresentationCompiler` interface but most important are: - We now have control where and how each presentation compiler method is run. Before it was always run on a `SingleThreadExecutor` created by the `PresentationCompiler`. The original behavior will stay with the standard `ScalaPresentationCompiler` interface. (There is another PR that refactors that part), - If there was bug in scheduler all versions were affected, On top of that this PR implements all things that will work out of the box: - Diagnostic provider - trivial implementation, previously not possible to LIFO task used by `Scala3CompilerAccess`. Will be super useful e.g for Scastie which will become a consumer of this new raw API. - `InteractiveDriver` compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe `ScalaPresentationCompiler` and `CancelTokens`. Here we can omit the cancel token support for now, because we would check for `Thread.interrupted()` along the `cancelToken.isCancelled` anyway, and we can now easily interrupt it from e.g `IO.interruptible` Those changes were adapted from my other PR's that required adjustment of `Scala3CompilerAccess` but I don't think it is ready / I'm not happy with current state of that refactor. In the future we should think of replacing the implementation of `ScalaPresentationCompiler` to use `RawPresentationCompiler` as underlying impl and just call it in safe way. The implementation was tested on the actual LSP server and it works fine. [Cherry-picked 582366c][modified]

`RawPresentationCompiler` is a direct, unsafe way to access presentation compiler interface provided in scalameta/metals#7841 It is up to the consumer to guarantee thread safety and sequential request processing. This solves many issues with the current `PresentationCompiler` interface but most important are: - We now have control where and how each presentation compiler method is run. Before it was always run on a `SingleThreadExecutor` created by the `PresentationCompiler`. The original behavior will stay with the standard `ScalaPresentationCompiler` interface. (There is another PR that refactors that part), - If there was bug in scheduler all versions were affected, On top of that this PR implements all things that will work out of the box: - Diagnostic provider - trivial implementation, previously not possible to LIFO task used by `Scala3CompilerAccess`. Will be super useful e.g for Scastie which will become a consumer of this new raw API. - `InteractiveDriver` compilation cancellation by checking Thread.interrupted(). Future changes are required to make it work with safe `ScalaPresentationCompiler` and `CancelTokens`. Here we can omit the cancel token support for now, because we would check for `Thread.interrupted()` along the `cancelToken.isCancelled` anyway, and we can now easily interrupt it from e.g `IO.interruptible` Those changes were adapted from my other PR's that required adjustment of `Scala3CompilerAccess` but I don't think it is ready / I'm not happy with current state of that refactor. In the future we should think of replacing the implementation of `ScalaPresentationCompiler` to use `RawPresentationCompiler` as underlying impl and just call it in safe way. The implementation was tested on the actual LSP server and it works fine.

Add RawPresentationCompiler impl, diagnostic provider, interactive dr…

2404514

…iver will now check for Thread.isInterrupted cancellation

rochala commented Oct 3, 2025

View reviewed changes

rochala requested review from KacperFKorban and tgodzik October 3, 2025 22:27

Make tests not flaky

8001619

KacperFKorban reviewed Oct 6, 2025

View reviewed changes

Gedochao assigned tgodzik Oct 8, 2025

tgodzik reviewed Oct 8, 2025

View reviewed changes

project/Build.scala Outdated Show resolved Hide resolved

tgodzik reviewed Oct 8, 2025

View reviewed changes

presentation-compiler/src/main/dotty/tools/pc/CachingDriver.scala Show resolved Hide resolved

tgodzik reviewed Oct 8, 2025

View reviewed changes

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala Outdated Show resolved Hide resolved

tgodzik requested changes Oct 8, 2025

View reviewed changes

rochala added 2 commits October 10, 2025 02:15

Remove bsp4j, add doc, add test for code action

53c8eec

Interfaces version

baa9d4c

rochala requested a review from tgodzik October 17, 2025 08:29

rochala and others added 2 commits October 17, 2025 10:53

Merge branch 'main' into raw-presentation-compiler

786c1ca

Check for shouldReturnDiagnostcs

14da82b

tgodzik requested changes Oct 21, 2025

View reviewed changes

project/Build.scala Outdated Show resolved Hide resolved

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala Outdated Show resolved Hide resolved

presentation-compiler/src/main/dotty/tools/pc/DiagnosticProvider.scala Outdated Show resolved Hide resolved

rochala and others added 2 commits October 22, 2025 10:17

Address comments

8a7cfec

Merge branch 'main' into raw-presentation-compiler

9ec21ad

Fix test

98ea1f0

tgodzik approved these changes Oct 22, 2025

View reviewed changes

tgodzik merged commit 582366c into scala:main Oct 22, 2025
51 checks passed

WojciechMazur added this to the 3.8.0 milestone Oct 28, 2025

tgodzik mentioned this pull request Nov 6, 2025

Backport "Add unsafe RawPresentationCompiler implementation" to 3.3 LTS scala/scala3-lts#633

Open

Add unsafe RawPresentationCompiler implementation #24133

Add unsafe RawPresentationCompiler implementation #24133

Uh oh!

Conversation

rochala commented Oct 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KacperFKorban left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rochala Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgodzik left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgodzik commented Oct 22, 2025

Uh oh!

rochala commented Oct 22, 2025

Uh oh!

tgodzik left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

rochala Oct 8, 2025 •

edited

Loading