RFR: JDK-8193367: Annotated type variable bounds crash javac

[B. Blaser]

I've attached the nomenclature change you suggested.
I agree that 'setBound()' is more expressive.
Tier1 is still OK.

Cheers,
Bernard

On 14 June 2018 at 19:03, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Looks ok, I think I'd rather prefer setBound to bound(arg), as the name you
> chose doesn't make assignment explicit.
>
> Long term, I think we should find ways to avoid mutating the bound after
> creation... but I did some experimental work on this, and it's not a piece
> of cake, as you often need mutation when handling recursive bounds - e.g.
> set some initial bound first, then do a subst and set final bounds later (I
> think there's a bunch of methods in Types that use this idiom).
>
> Maurizio
>
>
>
>
> On 13/06/18 11:09, B. Blaser wrote:
>>
>> Here it is, in attachment.
>> It completely privatizes and virtualizes 'TypeVar.bound'.
>>
>> Apologies for not providing a web-rev, this is still on my to-do list...
>>
>> Any feedback is welcome (tier1 is OK),
>> Bernard
>>
>> On 11 June 2018 at 20:42, B. Blaser <bsrbnd at gmail.com> wrote:
>>>
>>> That's what I thought too but I wanted a confirmation before doing the
>>> whole job...
>>>
>>> Thanks,
>>> Bernard
>>>
>>> On 11 June 2018 at 19:23, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> I think this patch is a good start, but to be complete, we'd need to
>>>> completely virtualize access on the 'bound' field, otherwise we risk
>>>> turning
>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in Types
>>>> alone,
>>>> each of those could lead to issues with type annos.
>>>>
>>>> Maurizio
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk8193367b.patch
Type: text/x-patch
Size: 22996 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180616/e0d89c6c/jdk8193367b-0001.patch>