RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10]

[Archie Cobbs]

On Wed, 13 Aug 2025 20:42:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>>  - Remove an unnecessary field.
>>  - More simplification of LintMapper per review suggestions.
>>  - More simplification of LintMapper per review suggestions.
>>  - More refactoring to simplify LintMapper per review.
>>  - Refactor LintMapper to clean up internal type hierarchy per review.
>>  - Address a couple of review comments.
>>  - Merge branch 'master' into JDK-8348611
>>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251:
> 
>> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
>> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
>> 251:         List<LintRange> children                        // the nested declarations one level below this node
> 
> not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future

I think at one point I had something like that, but it made things more complicated. Plain binary search doesn't work when you are searching in a list of (possibly nested) intervals instead of a list of points, because there can be multiple matches (arbitrarily many in fact). I think it would require an [Interval tree](https://en.wikipedia.org/wiki/Interval_tree).

There is also another annoying detail, which is that the nesting is not always proper: in some oddball cases (none of which I can specifically remember) there can be an AST node whose starting position is before the starting position of its parent AST node (or ending position after its parent). These instances could cause an Interval tree type of algorithm to glitch out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274793914