Loosening requirements for super() invocation

[Archie Cobbs]

On Fri, Nov 4, 2022 at 11:27 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> A key aspect of this is identifying what code might be run during specific
> windows of time.  For the window between "super call" and "last final field
> assigned", we are worried about final field reads; for the window covering
> the entire ctor, we are worried about broader uses of `this`.
>

Good point - they are really two separate aspects of the overall "problem".

So perhaps there are two separate warnings we should be generating, each
with their own independent analysis/logic.

Doing this would also allow us to spread the "blame" more equitably.

So with the FilteredSet example:

   - FilteredSet's constructor should generate warning A for not assigning
   this.filter prior to super()
   - HashSet's constructor should generate warning B for invoking the
   potentially this-leaking method addAll()

This sounds like the right logical separation. One confirmation is that
correcting *either one* of the warnings would fix the bug. So each class
must be independently contributing to the overall danger level.


> To your point about "the superclass might downcast", this is something you
> can check for as something questionable to do with `this`.
>

Agreed - this should also generate warning B, because it represents a
possible route for 'this' to escape.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221104/5d60ea9a/attachment.htm>