RFR: 8341901: Using 'var' keyword switch pattern matching causes compiler error

[Vicente Romero]

On Thu, 17 Oct 2024 12:43:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 749:
>> 
>>> 747: 
>>> 748:         if (sym.kind == TYP) {
>>> 749:             result.setType(types.erasure(sym.type));
>> 
>> can we do this outside of TreeMaker? I mean TreeMaker could be used to generate trees for a phase for which erasure hasn't occurred yet. It should be the caller's option to decide if the obtained tree should be erased or not
>
> Doing this outside of TreeMaker would be fairly difficult (as that would mean the caller would need to traverse the created tree and clean the types).
> 
> This change is not strictly necessary to solve the problem - moving the `chk.validate` is enough. But, it seems to me that type attributes in the AST that are produced by the `TreeMaker.QualIdent` do not make much sense. Specifically, passing the ClassSymbol for `java.util.List` here will produce a tree whose `.type` will be `java.util.List<E>`, where `E` is the type variable from `java.util.List`, which has no meaning outside of `java.util.List`. In general, calling `QualIdent` with a `ClassSymbol`, I don't see how any type other than the erased one would make sense.
> 
> That sad - I can easily remove this part of the patch, the AST distortion is fairly small, at least at this time.

I see what you mean, then I think we should document in the method that the produced AST will be erased, also please check double check if the type of JCFieldAccess::selected needs to be erased too, I think we should be fine but just to make sure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21495#discussion_r1806636077