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 <[email protected]>:
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);
