Scala3doc: No DRI found for query
See original GitHub issueCompiler version
3.1.0
Minimized code
The trait Config
has docs that point to ConfigValue
.
* <p>
* Convert a <code>Config</code> to a JSON or HOCON string by calling
* [[#root root]] to get the [[ConfigObject]] and then call
* [[ConfigValue!.render:String* render]]
* on the root object, <code>myConfig.root.render</code>. There's also a variant
* [[ConfigValue!.render(options:org\.ekrich\.config\.ConfigRenderOptions)* render(ConfigRenderOptions)]]
* inherited from [[ConfigValue]] which allows you to control
* the format of the rendered string. (See {@link ConfigRenderOptions}.) Note
* that <code>Config</code> does not remember the formatting of the original
* file, so if you load, modify, and re-save a config file, it will be
* substantially reformatted.
Here is the generated docs: https://www.javadoc.io/doc/org.ekrich/sconfig_3/latest/index.html#org.ekrich.config.Config
Output
[info] Main Scala API documentation to /Users/eric/workspace/sconfig/sconfig/jvm/target/scala-3.1.0/api… [info] Skipping unused scalacOptions: -deprecation, -feature [warn] – Warning: sconfig/shared/src/main/scala/org/ekrich/config/Config.scala:171:6 - [warn] 171 |trait Config extends ConfigMergeable { [warn] | ^ [warn] | No DRI found for query: ConfigValue!.render:String* [warn] one warning found [info] Main Scala API documentation successful.
Expectation
Works as it did in older versions. See https://www.javadoc.io/doc/org.ekrich/sconfig_2.11/latest/index.html#org.ekrich.config.Config
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:9 (5 by maintainers)
Top GitHub Comments
This problem is related to: #11119 We don’t support method overloading in our member lookup like the old Scaladoc does. This bug shows that our query parser is also not 100% compliant with the old parser. I think this problem should be resolved together with method overloading support.
@ekrich The problem with overloads is that it’s not supported by the query parser which was rewritten in Scaladoc 3. So, we are always picking the same method ignoring the overload. See: https://github.com/lampepfl/dotty/issues/11119
The rewrite was necessary since the parser in Scaladoc 2 was very much coupled with the Scaladoc’s internals and it wasn’t an easy task to port it.