RFR: 8355753: @SuppressWarnings("this-escape") not respected for indirect leak via field

[Vicente Romero]

On Mon, 28 Apr 2025 17:08:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 387:

> 385:         // Sort warnings so redundant warnings immediately follow whatever they are redundant for, then remove them
> 386:         warningList.sort(Warning::sortByStackFrames);
> 387:         AtomicReference<Warning> previousRef = new AtomicReference<>();

just curious: why do we need to deal with AtomicReference here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114462853