RFR 8200199: javac suggests to use var even when var is used

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Mar 28 13:07:30 UTC 2018


I think the fact that the position is unset is deliberate - after all 
the var type is not really there - it just appears magically as a 
special side-effect of attributing a 'var' declaration (so that the rest 
of the pipeline can work as usual). In that sense, I believe that not 
having a position is correct: there's no source position that 
corresponds to the (synthetic) variable type inferred for a 'var' 
declaration. This is consistent with other places where we generate 
synthetic trees.

Maurizio


On 28/03/18 13:40, Vicente Romero wrote:
> question: shouldn't the fact that the vartype in the variable 
> declaration doesn't have the position of `var` be a bug?
>
> Vicente
>
> On 03/28/2018 06:52 AM, Maurizio Cimadamore wrote:
>> Hi,
>> there is an issue with the local variable inference finder: the 
>> finder reports possible cases where 'var' could be used even when the 
>> developer has already used 'var'. This is due to a timing issue with 
>> which the analyzer runs - by the time it runs, variable types have 
>> already been written into the AST by Attr - so the call to 
>> JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look 
>> to see as to whether the tree type == null.
>>
>> Since the var types corresponding to implicitly inferred types are 
>> synthetic and have no position set (see 
>> Attr::setSyntheticVariableType) I decided to use that property 
>> instead to decide as to whether the analyzer should, or should not 
>> consider a given variable declaration. This seems to be a good 
>> pragmatic solution. In the long run we should probably consolidate 
>> the treatment of implicitly inferred variables, and have some kind of 
>> common way to speak about them (e.g. both locals and implicit lambda 
>> parameters).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8200199/
>>
>> Cheers
>> Maurizio
>>
>



More information about the compiler-dev mailing list