This is a follow up ticket from https://bugs.openjdk.java.net/browse/JDK-8062373 (Coins - <>
inference with anonymous classes) to investigate what exactly (if anything) needs to change
with respect to how the AST should appear to a Tree API client when certain types are elided
in the source code and are inferred during attribution.
Specifically after <> inference (with or without anonymous classes in the picture), should the
compiler "fill in" the diamond in the AST with tree nodes representing the inferred elided types
or whether a client should rely on other "decorations" in the tree to discover the elided types ?
One school of thought would be to leave the tree to be a pure AST representation of the source.
But in general javac munges the tree in so many ways that this model is not the norm.
I'll investigate what exactly needs to be done.
inference with anonymous classes) to investigate what exactly (if anything) needs to change
with respect to how the AST should appear to a Tree API client when certain types are elided
in the source code and are inferred during attribution.
Specifically after <> inference (with or without anonymous classes in the picture), should the
compiler "fill in" the diamond in the AST with tree nodes representing the inferred elided types
or whether a client should rely on other "decorations" in the tree to discover the elided types ?
One school of thought would be to leave the tree to be a pure AST representation of the source.
But in general javac munges the tree in so many ways that this model is not the norm.
I'll investigate what exactly needs to be done.
- relates to
-
JDK-8024098 javac syntax tree should more closely model the source code
- Open
-
JDK-8062373 Project Coin: diamond and anonymous classes
- Closed