On Fri, 13 Jan 2023 15:08:59 GMT, Archie L. Cobbs <d...@openjdk.org> wrote:

>>> I guess I was confused because, while subclasses are a particularly sneaky 
>>> case where uninitialized values can show up, the above leak seems 
>>> potentially dangerous as well...
>> 
>> Yes - and this very question did come up in the discussions around this 
>> warning (see amber-dev).
>> 
>> The decision was to go with drawing the "warning boundary" at the 
>> compilation unit. The reasoning is that (a) this aligns with the compiler's 
>> "knowledge boundary", i.e., we can know for sure from code inspection, and 
>> also (b) focuses the warning on the particularly pernicious aspect of these 
>> bugs, which is that they arise from the non-obvious interaction among two or 
>> more files - even when looking at any single one of those files, there 
>> doesn't seem to be any apparent problem. In other words, we decided "not to 
>> try to save any single source code from itself".
>> 
>> But I think it's still an interesting question. Maybe experience will 
>> provide more guidance over time.
>
>> Something seems to be up with the lint description for this-escape - compare 
>> this:
> 
> Oops, will fix - thanks.

> The decision was to go with drawing the "warning boundary" at the compilation 
> unit. The reasoning is that (a) this aligns with the compiler's "knowledge 
> boundary", i.e., we can know for sure from code inspection, and also (b) 
> focuses the warning on the particularly pernicious aspect of these bugs, 
> which is that they arise from the non-obvious interaction among two or more 
> files

Sorry for being picky - you mention this "compilation unit" boundary before, 
but this is not really the reason here. Note that in my example B constructor 
calls out to a static method that is "outside" the boundary. The reason as to 
why my example is not flagged is simply that "escaping" is defined as "escaping 
into a subclass method", not just "escaping from the constructor (into some 
other compilation unit)".

-------------

PR: https://git.openjdk.org/jdk/pull/11874

Reply via email to