groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Milles (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GROOVY-8210) Unicode escape sequence in string literal yields incorrect source position
Date Wed, 31 May 2017 18:18:04 GMT

     [ https://issues.apache.org/jira/browse/GROOVY-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eric Milles updated GROOVY-8210:
--------------------------------
    Description: 
This seems related to GROOVY-4378.  If I enter {code}'\u0047'{code} into the Groovy Console
and inspect the AST, I find the string literal's ConstantExpression has been assigned colums
6 to 9.  A start position of 6 propagates to the parent return statement, block statement,
etc.  The start position should be column 1.

I believe the UnicodeEscapingReader is stepping in front of the parser and so it never gets
to process the original source characters '\', 'u', '0', '0', '4', '7'.

Having incorrect source location for string literals such as this inhibits proper editing/refactoring
in the IDE.

  was:
This seems related to GROOVY-4378.  If I enter {code}'\u0047'{code} into the Groovy Console
and inspect the AST, I find the string literal has been assigned colums 6 to 9.  A start position
of 9 propagates to the parent return statement, block statement, etc.

I believe the UnicodeEscapingReader is stepping in front of the parser and so it never gets
to process the original source characters '\', 'u', '0', '0', '4', '7'.

Having incorrect source location for string literals such as this inhibits proper editing/refactoring
in the IDE.


> Unicode escape sequence in string literal yields incorrect source position
> --------------------------------------------------------------------------
>
>                 Key: GROOVY-8210
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8210
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Eric Milles
>
> This seems related to GROOVY-4378.  If I enter {code}'\u0047'{code} into the Groovy Console
and inspect the AST, I find the string literal's ConstantExpression has been assigned colums
6 to 9.  A start position of 6 propagates to the parent return statement, block statement,
etc.  The start position should be column 1.
> I believe the UnicodeEscapingReader is stepping in front of the parser and so it never
gets to process the original source characters '\', 'u', '0', '0', '4', '7'.
> Having incorrect source location for string literals such as this inhibits proper editing/refactoring
in the IDE.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message