Fix absolute path handling in SemanticdbTaskListener.absolutePathFromUri

[lihaoyi]

The previous code was off by one:

• If given a relative path vf://tmp/foo/bar/baz, it would crash with unsupported URI
• If given an absolute path vf://tmp//foo/bar/baz, it would incorrectly produce a relative path foo/bar/baz using the absolute path's segments, which would typically duplicate the -sourceroot value and result in an invalid path

Looking at the code, it seems like it is simply splitting by 1 too many slashes: if we want everything after the vf://tmp/, we need to .split('/', 4) rather than .split('/', 5). This seems fixes both misbehaviors listed above:

• If given a relative path vf://tmp/foo/bar/baz, it extracts the relative foo/bar/baz, which is then appended as a sub-path by options.sourceroot.resolve
• If given an absolute path vf://tmp//foo/bar/baz, it extracts the absolute /foo/bar/baz, which then remains unchanged and is returned by options.sourceroot.resolve

Test plan

Tested manually, a local sbt publishLocal with these changes fixes downstream issues in tools that consume the semanticdb e.g. scalameta/metals#7913

[lihaoyi]

CC @antonsviridov-src since you seem to be the most active maintainer

[jupblb]

Thanks for the contribution. Unfortunately, we've recently dropped support for Scala and no longer use SBT/Zinc. Closing this PR as no longer needed.

[lefou]

That's a quite interesting reason to reject a PR. You prefer to have erroneous code in your code base because you don't use it. Strange. Why you don't delete the whole support for SBT/Zinc then?

[jupblb]

We did delete the whole support for SBT/Zinc. This PR is no longer relevant.

[tgodzik]

We've inlined the whole implementation into metals v2 for quicker iteration, so this is not an issue https://github.com/scalameta/metals/tree/main-v2/semanticdb-javac/src/main

[lefou]

We did delete the whole support for SBT/Zinc. This PR is no longer relevant.

My bad. I looked in main to check, but missed it was the main branch of the fork.

[jupblb]

We've inlined the whole implementation into metals v2 for quicker iteration, so this is not an issue

That's honestly good to hear. I was not aware that semanticdb-javac was used in metals (if so I'd reach out before making the decision to drop support for Scala). We lost a bit of institutional knowledge after @antonsviridov-src left Sourcegraph. :/

Thanks for paying attention and looking into this.