scala / scala3

The Scala 3 compiler, also known as Dotty.
https://dotty.epfl.ch
Apache License 2.0
5.88k stars 1.06k forks source link

doctool - external links regex does not consider relative paths #19758

Open bishabosha opened 8 months ago

bishabosha commented 8 months ago

The -external-mappings setting at use site should consider paths relative to the classpath entry's "root", currently it seems to be based on absolute paths

Compiler version

3.4.0

Minimized code

use this setting with the scaladoc command, in a Scala CLI project, e.g. https://github.com/bishabosha/enum-extensions (by default scala-cli currently sets this setting implicitly)

-external-mappings:.*scala.*::scaladoc3::https://scala-lang.org/api/3.x/

Output

see an example here https://javadoc.io/doc/io.github.bishabosha/enum-extensions_3/latest/enumextensions/numeric/NumericOps$.html,

the links for enumextensions.numeric.NumericOps.Modular clearly is treated as matching .*scala.*

Expectation

in enum extensions, no package mentions scala, so the regex should not match.

on a meta level, why is this regex matching on file system paths, I would assume that it matches on the fully qualified name of the symbol?

Notes

my current theory is this happens because Scala CLI projects classes have an absolute path including .scala-build/, so therefore matches the regex.

sure, to fix this in a Scala CLI project you can adjust the regex to *scala/.*, however these absolute paths prevent sensible usage if someone has a project called e.g. jwt-scala (a real project)

Florian3k commented 8 months ago

on a meta level, why is this regex matching on file system paths, I would assume that it matches on the fully qualified name of the symbol?

Matching on fully qualified name seems to be the reasonable way to do this. I've no idea why it works that way. We may want to change that, but it'll probably break someone's workflow.

Another option would to be to add new option, eg. -external-mappings-fqn which would work on fully qualified names.