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

[Maurizio Cimadamore]

On Tue, 29 Jul 2025 18:10:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor LintMapper to clean up internal type hierarchy per review.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 183:
> 
>> 181:     private class FileInfo {
>> 182: 
>> 183:         final MappedDeclNode rootNode = new MappedDeclNode(rootLint);   // tree of this file's "interesting" declaration nodes
> 
> I still find the design a bit odd here. We create an "empty" root node here, but then in the constructor we set up all its children. Maybe we should create the full "node" from the original `JCCompilationUnit` tree (in a single shot) ? Also, I can't quite figure out if we end up adding both a `Decl` and a `MappedDecl` as children of the same parent decl? Perhaps, if the only difference between mapped and non-mapped decl is that the former have a Lint object, just having a single decl class with a mutable Lint field that is only set once might work?
> 
> Meta-comment -- I also realize how a lot of this could probably be avoided if we could just stash the Lint directly in the corresponding tree? (e.g. if we could do that, then we'd just need something to "find" the most specific tree given a position and see if it has a `Lint` set. We'd probably still need a map from source files to compilation unit trees)

What I'm trying to say here is: having things in a side-map adds costs. Because, regardless of whether warnings are enabled or not, we're still going to add things to the `LintMapper` side-map. At which point it might be "cheaper" (memory-wise) to just add a field to the tree, and not having to "replicate" a tree-like structure inside `LintMapper` ?

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

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