RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9]

[Archie L. Cobbs]

On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use more idiomatic test for java.lang.Object.
>>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>>  - Fix formatting issue with the "this-escape" --help-lint description.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:
> 
>> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>> 1087:         visitScoped(tree, false, t -> {
>> 1088:             while (true) {
> 
> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times

The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.

That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).

If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).

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

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