There are some AST nodes that we synthesize during parsing - mainly
enums. It would be nice to have a proper representation for enum ASTs. I
believe Jan has already done some work in this area, so you might want
to ask him.
There's also an issue with string concatenation nodes: it is not too
infrequent to have very very long string concat chains. The current
strategy is to turn string concat into a binary op, which means you need
N -1 nested nodes to chain N strings together. It's not much of a
problem in terms of memory as it is in terms of stack traces: the stack
you need to visit a string concat grows with the number of elements
being concatenated. It is not uncommon to get stack overflows on string
concatenation. The compiler currently has few hacks in place to try and
combine things together as much as possible (one attempt is done in
Parser, another is done in Attr/ConstFold) - but this is very brittle
and bad for IDEs which then lose correspondency with original source
positions.
enums. It would be nice to have a proper representation for enum ASTs. I
believe Jan has already done some work in this area, so you might want
to ask him.
There's also an issue with string concatenation nodes: it is not too
infrequent to have very very long string concat chains. The current
strategy is to turn string concat into a binary op, which means you need
N -1 nested nodes to chain N strings together. It's not much of a
problem in terms of memory as it is in terms of stack traces: the stack
you need to visit a string concat grows with the number of elements
being concatenated. It is not uncommon to get stack overflows on string
concatenation. The compiler currently has few hacks in place to try and
combine things together as much as possible (one attempt is done in
Parser, another is done in Attr/ConstFold) - but this is very brittle
and bad for IDEs which then lose correspondency with original source
positions.
- is blocked by
-
JDK-8215371 Better nodes for concatenated string literals
- Open