You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and now we don't know to which type the type arguments apply. Moreover, Java 1.8+ makes it possible to add annotations to the individual segments, such that e.g. Map.@Foo Entry<K,V> is perfectly legal. But our parser chokes on it for now (related to #997). If we are to add support for that, we'd better do it in a sensible way, such that the annotations don't end up all mixed whenever there's several of them.
I think for those reasons, we'd have interest in making ClassOrInterfaceType conform to the JLS (our ClassOrInterfaceType would be the JLS's ClassType), which would make the above examples be parsed recursively, (see examples at the end). I think this may help type resolution too.
ClassOrInterfaceType currently has a single image for the entire type. E.g. the type
Map.Entry<K,V>
is parsed asThis looks ok. Now, the invented type
Foo<K>.Bar.Brew<V>
is parsed asand now we don't know to which type the type arguments apply. Moreover, Java 1.8+ makes it possible to add annotations to the individual segments, such that e.g.
Map.@Foo Entry<K,V>
is perfectly legal. But our parser chokes on it for now (related to #997). If we are to add support for that, we'd better do it in a sensible way, such that the annotations don't end up all mixed whenever there's several of them.I think for those reasons, we'd have interest in making ClassOrInterfaceType conform to the JLS (our ClassOrInterfaceType would be the JLS's ClassType), which would make the above examples be parsed recursively, (see examples at the end). I think this may help type resolution too.
Map.Entry<K,V>
Foo<K>.Bar.Brew<V>
Map.@Foo Entry<K,V>
The text was updated successfully, but these errors were encountered: