RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage
jonathan.gibbons at oracle.com
Tue Feb 7 02:05:01 UTC 2017
reviewed, built, tested and pushed
On 02/06/2017 05:51 PM, Liam Miller-Cushon wrote:
> Thanks for the review! I fixed the nits, here's the latest version:
> The changeset is attached.
> On Mon, Feb 6, 2017 at 3:40 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
> 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
>> 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
> 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.*
> Otherwise, looks OK.
> I think this is small and safe enough for 9.
> -- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev