[jira] [Comment Edited] (GROOVY-9894) Dollar slashy string ending in escaped dollar parses in 2.0 fails in 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Comment Edited] (GROOVY-9894) Dollar slashy string ending in escaped dollar parses in 2.0 fails in 3.0

Eric Milles (Jira)

    [ https://issues.apache.org/jira/browse/GROOVY-9894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17264519#comment-17264519 ]

David Stafford edited comment on GROOVY-9894 at 1/14/21, 1:11 AM:
------------------------------------------------------------------

Looking at it harder, I wonder how it ever worked.  I now see the /$ then a $/ then a $ followed by the rest of the document, which doesn't end until we happen to bump into another /$ much later.  How the old parser parsed it the way I (and Eclipse syntax highlighting) thought, ending after
{code:java}
+)/$$/${code}
So my mistake, although there's an issue in the 2.5 parser.  My fix is
 static final String uriRegex = $/^/([a-zA-Z0-9]+)$/$$/$
 or possibly
 static final String uriRegex = $/^/([a-zA-Z0-9]+)$/$/$
 Captain Hindsight says it's too bad the syntax wasn't @/^/([a-zA-Z0-9]+)/$/@ since @ isn't used in any regex I know of.


was (Author: dukeweaselton):
Looking at it harder, I wonder how it ever worked.  I now see the /$ then a $/ then a $ followed by the rest of the document, which doesn't end until we happen to bump into another /$ much later.  How the old parser parsed it the way I thought (and Eclipse syntax highlighting also marks it as ending after +)/$$/$.

So my mistake, although there's an issue in the 2.5 parser.  My fix is
static final String uriRegex = $/^/([a-zA-Z0-9]+)$/$$/$
or possibly
static final String uriRegex = $/^/([a-zA-Z0-9]+)$/$/$
Captain Hindsight says it's too bad the syntax wasn't @/^/([a-zA-Z0-9]+)/$/@ since @ isn't used in any regex I know of.

> Dollar slashy string ending in escaped dollar parses in 2.0 fails in 3.0
> ------------------------------------------------------------------------
>
>                 Key: GROOVY-9894
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9894
>             Project: Groovy
>          Issue Type: Bug
>          Components: lexer
>    Affects Versions: 3.0.5, 3.0.7
>         Environment: Windows 10
>            Reporter: David Stafford
>            Priority: Major
>
> This program fails to compile in 3.0.7 (and 3.0.5) but parses in 2.5: 
> {code:java}
> public class TestClass {
>   static final String uriRegex = $/^/([a-zA-Z0-9]+)/$$/$
>   public TestClass(
>   ) {
>    // String uuid = UUID.randomUUID().toString();
>    // "/${evenme}/${uuid}.xml"
>   }
> }
> {code}
> error is:
> {noformat}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
> src\main\groovy\com\broadridge\datafabric\publisher\enrichment\formatters\TestClass.groovy: 7: Unexpected input: '$/$\r\n\r\n\tpublic TestClass(\r\n\t) {\r\n\t\t//\t\tString uuid = UUID.randomUUID().toString();\r\n // "/${evenme}/${uuid}.xml"' @ line 7, column 35.
>  // "/${evenme}/${uuid}.xml"
>                            ^
> 1 error
> {noformat}
>  In my actual code, only the comment is pointed out as incorrect, which was very disconcerting.  The issue is the $/$ in uriRegex is taking precedence over the $$ (possibly because its a longer but later match?).  This means the lexer thinks we're still in a dollar-slashy string.  What it should do is consume the $$, turn it into a $ (escaped dollar), then hit the /$, and end the string.
> My workaround is to convert to a slashy string, but that means I need to escape all the forward slashes in the regex, and that's what dollar slashy strings are good for (avoiding extra escapes).  As it stands, in 3.0 a dollar-slashy can't end with a dollar, which is a pretty common character for a regex to end with.
> This came up when converting a large codebase to groovy 3.0, getting bizarre error messages pointing far away from the actual issue.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)