Open bishabosha opened 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.
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 pathsCompiler 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)