Strike out usage of deprecated symbols

[kpodsiad]

Is your feature request related to a problem? Please describe.

When I use deprecated method, in completions I see that it's deprecated, but after choosing completion, method is rendered as normal one.

Describe the solution you'd like

It should be visible that symbol is deprecated, for instance example from rust:

There is DiagnosticTag for that purpose in diagnostic. I don't know if this can be achieved in other way than through diagnostics.

Describe alternatives you've considered

rely on scalac's deprecation and compilation warnings

• metals can detect such diagnostics and add deprecated tag to them, will work only if one has this settings enabled on they own
• metals can implicitly add this setting(?) - but then one will see such diagnostic even if they didn't enable deprecation flag

Additional context

No response

Search terms

deprecation diagnostics

[tgodzik]

I was thinking that maybe semantic tokens could help here, but it seems that setting deprecated doesn't do anything currently 🤔 It might depend on the theme? Or maybe something is wrong in the semantic highlight PR? Or the modifier don't do anything right now. Not sure.

The best approach now is to rely on -deprecated flag and add the specific tag to diagnostics. Though we would need to detect is deprecated string, which is not perfect.

[ckipp01]

Though we would need to detect is deprecated string, which is not perfect.

Note that in Scala 3 everything is there to instead give that diagnostics an errorMessageID and we could just detect that. As of 3.2.x they are being forwarded and Mill and sbt are also forwarding them for us to use.

[tgodzik]

Note that in Scala 3 everything is there to instead give that diagnostics an errorMessageID and we could just detect that. As of 3.2.x they are being forwarded and Mill and sbt are also forwarding them for us to use.

Och, we might also need to change that in Bloop. Do you have any links to how it's being handled in sbt?

Coming back to semantic tokens, it does actually work, but is limited by the theme. By doing:

  "editor.semanticTokenColorCustomizations": {
    "[Adapta Nokto]": {
      "rules": {
        "keyword": "#ffffff2f",
        "*.deprecated": {
          "fontStyle": "strikethrough"
        }
      }
    }
  }

I was able to get it to work.

Also changed the color for keyword, which might not have been the best choice 😅

[tgodzik]

Plus side of this approach is that we will be able to mark things as deprecated without the additional diagnostics.

[kpodsiad]

@tgodzik will just following work?

"editor.semanticTokenColorCustomizations": {
  "rules": {
    "*.deprecated": {
      "fontStyle": "strikethrough"
    }
  }
}

and if yes, is it possible for extension to contribute to editor settings? 🤔

[ckipp01]

Och, we might also need to change that in Bloop. Do you have any links to how it's being handled in sbt?

I started work on this in scalacenter/bloop#1750. Everything should be there, but I had some ScalaJS failures that I never had time to look into.

[Arthurm1]

Could this be added now? BSP supports the same diagnostic tags as LSP so it would be nice pass them on to the IDE.

BSP tags
LSP tags

[Arthurm1]

Ah - I see here that the unnecessary LSP tag is set depending on the code in the BSP diagnostic.

And here and here it looks like Bloop doesn't set any BSP diagnostic tags.

Shouldn't this be done in the BSP server (bloop, SBT, mill) and then Metals should just pass that on to the LSP diagnostic?

[tgodzik]

Shouldn't this be done in the BSP server (bloop, SBT, mill) and then Metals should just pass that on to the LSP diagnostic?

That's the idea, we should pass it the whole chain from the compiler unfortunately.

[Arthurm1]

It's not a big deal - just nice to have. I was looking at the Java diagnostics sent to Metals via BSP and obviously java's code value is completely unrelated to Scala's code value