RFR: 8329951: `var` emits deprecation warnings that do not point to the file or position [v4]

[Liam Miller-Cushon]

On Wed, 4 Jun 2025 15:55:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5721:
>> 
>>> 5719:             tree.vartype = make.at(tree.pos()).Erroneous();
>>> 5720:         } else {
>>> 5721:             tree.vartype = make.at(tree.pos()).Type(type);
>> 
>> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?
>
>> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?
> 
> I'm not sure (due to my own ignorance, not skepticism). How does the lack of ending position manifest? FWIW there appear to be lots of instances in the compiler where `make.at()` is used to create some AST node with a given start position, but where the end position is never being set. How is this case different? Etc.

I'm not sure if manifests in behaviour in javac, but it affects `com.sun.source.util.SourcePositions#getEndPosition`, so it's observable to plugins. Most local variables types generally have start/end positions, `var` is an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2126972119