Jump-to-Definition in Java Sources doesn't work when module is nested in other module's source root

[lihaoyi]

Follow up to #7913

Describe the bug

Download and unpack this zip

test.zip

This contains the following files:

build.mill
mill
Foo.java
foo/test/src/foo/FooTest.java
foo/src/foo/Foo.java
.mill-version

Open it in VSCode Metals with #7914 included and import the project (or alternately, update the version of Mill to a locally built version including this upstream fix from scip-java sourcegraph/scip-java#827)

Jump-to-definition to third-party imports in foo/src/Foo.java does not work

The reason seems to be that when the top-level ./Foo.java exists, Mill reports ./ as a module/source root for the top-level Foo.java file, which then causes jump-to-definition in foo/src/Foo.java to fail.

Notably, renaming the top-level ./Foo.java to ./Foo.java2 resolves the issue, as ./Foo.java2 is not recognized as a program file and does not create a source root in the enclosing folder, which results in Jump-to-Definition working again when the project is re-imported

This failure mode doesn't appear to happen to Foo.scala files for some reason, only Java files.

Jump-to-definition to external libraries works when opening this small project in IntelliJ BSP

Expected behavior

No response

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

v1.6.3

Scala version/s

Extra context or search terms

No response

[tgodzik]

I managed to get native Java compiler go to definition working, which should be helpful in cases like this #7920

It seems to work now with it, tough we might need to check later with this case whether it doesn't cause any other problems

[lihaoyi]

I'm curious how did it work before without native Java compiler support? Because without the enclosing module, jump-to-definition already works in foo/src/Foo.java.

[tgodzik]

It was using semanticdb for that, it seems we might not be finding it correctly in case of this project