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

[Vicente Romero]

bike shedding: shouldn't it be getBound / setBound instead of bound / 
setBound

Vicente

On 06/16/2018 08:13 AM, B. Blaser wrote:
> 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
>>