RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.

[Jonathan Gibbons]

On 6/1/20 4:59 AM, Hannes Wallnoefer wrote:
> Thanks for the review, Jon.
>
>> Am 29.05.2020 um 19:03 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>>
>>
>> I think the proposed behavior, that 'foo.bar' resolves in favor of a type or package, is OK, and favors backwards compatibility, which is good, although it would not be my first choice if we were starting over from scratch in an alternate reality.
>>
>> In DocCommentParser, why do you go out of your way to store the `trimmedSig` in the tree, and not the sig as found? Does this affect the source-fidelity when printing out the tree?
>>
> The trailing slash is only needed to disambiguate the intention, but it needs to be removed in order for the module lookup to succeed.
>
> Hannes
>
>
>> -- Jon
>>

Hannes,

Unless I'm missing something, it still seems wrong to put the trimmedSig 
in the tree, instead of the sig.  You already have the module name 
available as a separate parameter to the newReferenceTree call.

I'm concerned that if you parse the comment, then print it (i.e. use 
.toString()) then the output will not be the same as the original.

-- Jon


  486         String sig = newString(pos, bp);
  487

  488
  489         try {
490 ReferenceParser.Reference ref = new ReferenceParser(fac).parse(sig);
491 // Remove trailing slash that marks this as a module reference
492 String trimmedSig = sig.endsWith("/") ? sig.substring(0, 
sig.length() -1) : sig;
493 return m.at(pos).newReferenceTree(trimmedSig,
494 ref.moduleName, ref.qualExpr,
495 ref.member, ref.paramTypes)
496 .setEndPos(bp);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20200601/d5cc2460/attachment.htm>