RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage

[Jonathan Gibbons]

On 02/06/2017 10:45 AM, Liam Miller-Cushon wrote:
> Hi, have you had a chance to look at the latest version of the patch?
>
> And would it make sense to defer to 10?
>
> On Sat, Jan 14, 2017 at 3:37 PM, Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     On Thu, Jan 12, 2017 at 1:46 PM, Jonathan Gibbons
>     <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>     wrote:
>
>         Is there any good reason not to do so?
>
>
>     I don't think so, thanks. I had thought that it would add
>     implementation complexity and wasn't as obviously useful as
>     supporting top-level and array elements values. However I realized
>     that matchAnnoToTree can be generalized to search recursively for
>     values, so it ends up being simpler. And as you point out, it
>     offers the best flexibility.
>
>     I have uploaded a new version of the patch that searches recursively:
>     http://cr.openjdk.java.net/~cushon/6388543/webrev.01/
>     <http://cr.openjdk.java.net/%7Ecushon/6388543/webrev.01/>
>
>

http://cr.openjdk.java.net/~cushon/6388543/webrev.01/test/tools/javac/processing/messager/6388543/T6388543.java.html
Nit: in the @modules, you don't need to specify java.compiler as well as 
jdk.compiler, since the latter requires the former.
Nit: it is not common to see javax.* imports sorted before java.* imports.

Otherwise, looks OK.

I think this is small and safe enough for 9.

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170206/62b50f92/attachment.html>