fixes range deriving for constructs incl classes/interfaces

[Strum355]

Uses text search derived from previous com.sun.source lsif-java (Kotlin edition), which is originally derived from georgewfraser's java language server. Closes #109

Of particular note is that the current changes cause definition occurence to not be emitted. The reference to this no longer existing definition occurrence still gets emitted, we can either follow up with a PR or fix it in this PR.

I feel like moving parts of SemanticdbVisitor.semanticdbRange(...) to the RangeFinder class to keep more of the logic together, but I will revisit this tomorrow.

[olafurpg]

This looks great! Really nice to have this bug fixed. A few minor comments on style and performance.

I recommend running the benchmarks https://sourcegraph.github.io/lsif-java/docs/benchmarks.html just to validate if the optimizations make a difference. I suspect you won't see a difference in caching the file contents from the compilation unit because we compile virtual files in the benchmark, but the speedup might actually be important for build tools that use a different source file implementation.

[olafurpg]

Minor: might be worth commenting why this is needed here. It looks like we're specifically targeting only constructors? Is there a difference between this and name.contentMatches("<init>")? Is it possible to reuse the logic between this line and the one in RangeFinder?

[Strum355]

My thinking at the time was that only the no-param constructor would ever be generated, but I realise now this doesn't hold true for the new record class types, so I'll revisit this line.

[olafurpg]

We can BTW add Java 15 code to the test suite. Alternatively, we can change the default minimized project to Java 15

[olafurpg]

I wouldn't worry too much about Java 15 however, we can deal with it later. I suspect very few users are on Java 15 right now.

[Strum355]

JDK 1.8.0_282

This branch:

[info] Benchmark                           (lib)  Mode  Cnt     Score    Error  Units
[info] CompileBench.compile            bytebuddy    ss   10  1371.189 ± 46.755  ms/op
[info] CompileBench.compile                guava    ss   10  1860.100 ± 94.912  ms/op
[info] CompileBench.compileSemanticdb  bytebuddy    ss   10  1684.466 ± 32.033  ms/op
[info] CompileBench.compileSemanticdb      guava    ss   10  2292.896 ± 45.351  ms/op

Current main:

[info] Benchmark                           (lib)  Mode  Cnt     Score    Error  Units
[info] CompileBench.compile            bytebuddy    ss   10  1379.276 ± 37.184  ms/op
[info] CompileBench.compile                guava    ss   10  1870.692 ± 95.841  ms/op
[info] CompileBench.compileSemanticdb  bytebuddy    ss   10  1662.590 ± 39.720  ms/op
[info] CompileBench.compileSemanticdb      guava    ss   10  2282.368 ± 70.845  ms/op

[olafurpg]

Awesome, please ignore the perf comments.

LGTM 👍

[olafurpg]

Actually, we should still reuse the string for the compilation unit source code because it's unlikely to appear as a bottleneck in our benchmarks.

[olafurpg]

Minor comments

[olafurpg]

LGTM 👍 You may need to run fixAll to please the CI.

This is ready to merge 🚀