RFR: JDK-8181854: NullPointerException in com.sun.tools.javac.api.JavacTrees.getElement

[Jan Lahoda]

On 17.8.2018 17:15, Jonathan Gibbons wrote:
> Jan,
>
> Ideally, javadoc (i.e. the doctree API) should handle generic types.  As
> a partial solution, is it worth detecting, and ignoring '<...>' so that
> we treat 'List<E>' as 'List'.

For the DocTrees.getElement method, I don't think we can do much to 
handle the '<' - the method returns only Element/Symbol. Please note 
that in the patch, it will return (Element for) j.u.List for "List<E>", 
as the preceding "attr.attribType(ref.qualifierExpression, env)" will be 
able to attribute the type, and I've changed the subsequent check from 
Type.isErroneous() (which also checks validity of the "nested" types, 
like type parameters) to Type.hasTag(ERROR) which should only filter 
cases where the type itself is not resolvable.

For support for generic types, we could either add a simple:
TypeMirror DocTrees.getTypeMirror(DocTreePath)

Or even something more elaborate, that could allow to parse and 
attribute types from a string representation.

Thanks,
     Jan


>
> -- Jon
>
>
> On 8/17/18 6:25 AM, Jan Lahoda wrote:
>> Hi,
>>
>> The problem described in this bug is that when the source code
>> contains javadoc reference like:
>> {@link List<E> ...}
>> (which is not valid), calling DocTrees.getElement(DocTreePath) for the
>> reference leads to a NPE. The reason is that internally, the method
>> will call Attr.attribIdent for an AST that corresponds to "List<E>",
>> but attribIdent can only handle identifiers and member selects. The
>> proposed solution is to avoid calling attribIdent if the AST node is
>> not an identifier or member select.
>>
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8181854/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181854
>>
>> Any feedback is welcome.
>>
>> Thanks,
>>    Jan
>