Remove parens nodes during parsing

Date: Mon, 21 May 2001 20:27:10 -0700
From: Neal M Gafter <###@###.###>
To: James Gosling <###@###.###>
Subject: Re: Parens

James Gosling wrote:
> > 4391330 compiler accepts (Integer).toString(123)
>
> I have to admit that I'm surprised that this is supposed to be an error.
> I'm sure that compiler0 accepted it. I roamed throught the JLS for a while
> to find where this is prohibited, but I couldn't find it. Any hints?

There's just nothing in the grammar to support it. It certainly isn't
a parenthesized expression, because the contents aren't an expression.
The syntax for qualified names simply doesn't allow parens.

> > 4394546 get no err msg if label wrapped in parentheses
> > 4408036 Compiler incorrectly accepts "(i=2);" as a valid expession statement.
>
> Groan. This can be done directly in the Parser without constructing a Parens
> node -- it's ugly given the structure of the Parser, but after much staring
> I know how to do it.

Let me guess: add a private Tree field to Parser called lastParenthesizedExpression,
which is intialized to null and set every time a close paren is seen. Test
that the label (or expression) is not == the lastParenthesizedExpression in
this context and give an error message if it is. Did you have another strategy
in mind?

This is almost enough to eliminate the Parens node altogether (when not
generating jcov tables) ... but how do I handle (Integer).toString(123)?
I see the following options:
(1) change the language spec to allow it;
(2) insert the bug back into the compiler and close the report
as "will not fix";
(3) Using lastParenthesizedExpression in the Parser, insert a
Parens node on the left hand side of a qualified
expression when the source was parenthesized (but don't
use the Parens node anywhere else);
(4) Add a boolean to the qualified expression flagging when the
left-hand-side was parenthesized.

Personally, I vote for (3). What do you think?

> > In addition, those nodes are necessary to get correct source positions
> > for jcov table generation.
>
> Really? Could you explain more? This sounds wierd...

For jcov we generate a new table CharRangeTable that maps byte code
to source position at a much finer level than before. The spec for
this table requires the starting and ending positions of expressions
in many contexts - and this includes the parens. The positions of
the parens simply aren't available anywhere else. This table format
was originally designed for use as debugging information (I stole it
from Robert Field's draft for a JSR on extended debugging information),
and I expect it will eventually be used that way. I suspect this
information may be useful to IDE vendors if they ever decided to use
javac as part of their system.

> > > (I'd wager that most people would rather have the unparser include just exactly
> > > those parens that are actually necessary [with a group wanting extra parens in
> > > conditionals for Pascal-ish booleans])

If parens aren't in the trees, the unparser emits the
minimal parens required.