[
https://issues.apache.org/jira/browse/GROOVY-12425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-12425:
--------------------------------
Description:
h2. Description
Two parser diagnostics name a missing closer but point at the wrong token, or
name a different mistake. Both should match the caret already used for an
unclosed quote: one sentence, on the token that is wrong.
h3. Unclosed type argument
{{List<Integer name}} is parsed as the comparison {{List < Integer}} plus a
following argument list. The message was already {{Missing '>'}}, which is the
same advice as javac's {{> or ',' expected}}. The caret sat on {{List}}, often
many tokens away from the missing {{>}}.
The caret now sits on the first token of that argument list. An identifier
after {{T < U}} is an argument list, not a command argument, so the caret is
the start of the list. Extra spaces do not pull it back onto the space after
the type argument.
* {{List<Integer list2}} — caret on {{list2}}
* {{List<List<Integer> list2}} — caret on {{list2}}, after the inner {{>}}
* {{List<Integer name}} — two spaces; caret on {{name}}, not on the first space
* {{List < Integer 1, 2}} — caret on {{1}}
* {{List < Integer name foo}} — caret on {{name}}, not on {{foo}}
A comparison that is not two type names stays {{Unexpected input}}. {{list <
Integer name}} is one of those.
{noformat}
Missing '>' @ line 1, column 14.
List<Integer list2 = new ArrayList<Integer>()
^
{noformat}
h3. Unclosed slashy string
An unclosed {{/.../}} was reported as {{Unexpected input: '/'}}. {{/}} is also
the division operator, so a slashy string that never closes fell through to
that token.
It is now {{Unclosed string literal}}, with the caret on the opening {{/}}.
That is the same sentence and the same opener caret as an unclosed {{'}} or
{{"}}, and the same place javac marks {{unclosed string literal}}.
{noformat}
Unclosed string literal @ line 1, column 5.
s = /hello
^
{noformat}
The same message is used when the slashy string is only {{/}} at end of input,
and when the opener is on the line after {{=}}.
Division is unchanged:
* {{a / b}} stays division.
* A value, a line break, then {{/}}, then another value stays division. A
newline is not a left operand. {{9}} split across lines from {{3}} by {{/}}
still divides.
* A closed {{/ab/}} is still a string. {{//}} and {{/*}} are still comments.
{{$/}} is not treated as an unclosed string. {{$}} is an identifier, so
{{($/2)}}, {{$/=}}, and {{$//}} are division. An end-of-input alternative on
{{$/}} would reject those programs. An unclosed {{$/...}} therefore still
surfaces as a later error.
was:
The caret position is not accurate, column *14* should be better.
{code}
@Test
void 'unclosed type argument'() {
expectParseError '''\
|List<Integer list2 = new ArrayList<Integer>()
|'''.stripMargin(), '''\
|Missing '>' @ line 1, column 1.
| List<Integer list2 = new ArrayList<Integer>()
| ^
|
|1 error
|'''.stripMargin()
}
{code}
> Refine error message for unclosed type argument and unclosed slashy string
> --------------------------------------------------------------------------
>
> Key: GROOVY-12425
> URL: https://issues.apache.org/jira/browse/GROOVY-12425
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> h2. Description
> Two parser diagnostics name a missing closer but point at the wrong token, or
> name a different mistake. Both should match the caret already used for an
> unclosed quote: one sentence, on the token that is wrong.
> h3. Unclosed type argument
> {{List<Integer name}} is parsed as the comparison {{List < Integer}} plus a
> following argument list. The message was already {{Missing '>'}}, which is
> the same advice as javac's {{> or ',' expected}}. The caret sat on {{List}},
> often many tokens away from the missing {{>}}.
> The caret now sits on the first token of that argument list. An identifier
> after {{T < U}} is an argument list, not a command argument, so the caret is
> the start of the list. Extra spaces do not pull it back onto the space after
> the type argument.
> * {{List<Integer list2}} — caret on {{list2}}
> * {{List<List<Integer> list2}} — caret on {{list2}}, after the inner {{>}}
> * {{List<Integer name}} — two spaces; caret on {{name}}, not on the first
> space
> * {{List < Integer 1, 2}} — caret on {{1}}
> * {{List < Integer name foo}} — caret on {{name}}, not on {{foo}}
> A comparison that is not two type names stays {{Unexpected input}}. {{list <
> Integer name}} is one of those.
> {noformat}
> Missing '>' @ line 1, column 14.
> List<Integer list2 = new ArrayList<Integer>()
> ^
> {noformat}
> h3. Unclosed slashy string
> An unclosed {{/.../}} was reported as {{Unexpected input: '/'}}. {{/}} is
> also the division operator, so a slashy string that never closes fell through
> to that token.
> It is now {{Unclosed string literal}}, with the caret on the opening {{/}}.
> That is the same sentence and the same opener caret as an unclosed {{'}} or
> {{"}}, and the same place javac marks {{unclosed string literal}}.
> {noformat}
> Unclosed string literal @ line 1, column 5.
> s = /hello
> ^
> {noformat}
> The same message is used when the slashy string is only {{/}} at end of
> input, and when the opener is on the line after {{=}}.
> Division is unchanged:
> * {{a / b}} stays division.
> * A value, a line break, then {{/}}, then another value stays division. A
> newline is not a left operand. {{9}} split across lines from {{3}} by {{/}}
> still divides.
> * A closed {{/ab/}} is still a string. {{//}} and {{/*}} are still comments.
> {{$/}} is not treated as an unclosed string. {{$}} is an identifier, so
> {{($/2)}}, {{$/=}}, and {{$//}} are division. An end-of-input alternative on
> {{$/}} would reject those programs. An unclosed {{$/...}} therefore still
> surfaces as a later error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
