Semantic information output request

[Arthur McGibbon]

IDEs use semantic information to navigate and highlight/colour code.

By semantic info I mean something like...
```
  String foo;    // line 2
...
  println(foo);   // line 15
```
 On line 2 columns 3->9 there is a reference to `java.lang.String`
 On line 2 columns 10->13 there is a variable called `foo` of type
`java.lang.String`.
 On line 15 columns 11->14 there is a reference to a local variable `foo`
of type `java.lang.String`

So in an IDE I could run `Go to definition` on line 15 column 11 and be
taken to line 2 column 10.
Or I run `Go to definition` on line 2 column 5 and be taken to some
position in `java/lang/String.java`.

Currently IDEs have to parse the source file to discover this semantic
information.
Or they can use a compiler plugin like
https://github.com/sourcegraph/scip-java.

In the compiler plugin's case, semanticdb files are output alongside class
files.
The semantic db files can then be read by the IDE instead of it having to
parse the source.

The advantage of the plugin is that the parsing is driven by the compiler
so the semantic info should always be correct.  Also - the IDE doesn't have
to contain a java parser that must be up to date.

I think the plugin idea originally came from work on a plugin for Scala.
Since then, Scala has integrated the plugin code into its compiler so a
user can just specify a compiler option to get Scalac to output the
semanticdb files instead of having to download and configure a plugin.

I'd like to see the same happen with Java and have javac output semantic
files when supplied with the relevant javac option.

I'd also like to see these files outputted into `-sources.jar` files with
the original source. Or maybe in their own `-semantic.jar`.  It would mean
that IDEs no longer have to parse library files to be able to navigate
them, instead they'd just load directly from the distributed semantic files.

The benefits of this are reducing load on the many LSPs/IDEs out there,
speeding up the generation of this information (it's already in the
compiler) and ensuring correctness as the compiler should be the font of
all compilery knowledge.

regards
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240717/1985a72c/attachment-0001.htm>