Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression leading to incorrect capture when an action method is present #6201

Closed
p6rt opened this issue Apr 21, 2017 · 4 comments
Closed

Regression leading to incorrect capture when an action method is present #6201

p6rt opened this issue Apr 21, 2017 · 4 comments
Labels
regex Regular expressions, pattern matching, user-defined grammars, tokens and rules

Comments

@p6rt
Copy link

p6rt commented Apr 21, 2017

Migrated from rt.perl.org#131187 (status was 'resolved')

Searchable as RT131187$

@p6rt
Copy link
Author

p6rt commented Apr 21, 2017

From @jnthn

This is golfed from a File​::Ignore regression. This reproduces it​:

grammar Parser {
  token TOP { <matcher>+ }
  proto token matcher { * }
  token matcher​:sym<[]> { '[' <( <-[\]]>+ )> ']' }
  token matcher​:sym<lit> { <-[/*?[]>+ }
}
class RuleCompiler {
  # Simply commenting out this causes the matcher​:sym<lit> to get the
.txt it should. With
  # this, it gets ].txt instead.
  method matcher​:sym<[]>($/) { }
}
say Parser.parse('[AB].txt', :actions(RuleCompiler));

Commenting out the action method makes the final match tree correct.
Without it, the match tree ends up with the second matcher wrongly
capturing the ].

I've had trouble bisecting it due to unbuildable commits; the log is here​:

https://gist.github.com/Whateverable/119eb26d8ca245bf59ec05bc014c9fc2

It was fine in 2017.03 and broken in 2017.04, perhaps around the time of
the uncurse merge. I'm somewhat suspecting that, since it unified Match and
Cursor. This code may be a tricky edge case for the unification since it
uses the <( and )> constructs, which make the captured text and the text
matched by the cursor differ.

@p6rt
Copy link
Author

p6rt commented Apr 21, 2017

From @jnthn

On Fri, 21 Apr 2017 05​:44​:48 -0700, consulting@​jnthn.net wrote​:

This is golfed from a File​::Ignore regression. This reproduces it​:

grammar Parser {
token TOP { <matcher>+ }
proto token matcher { * }
token matcher​:sym<[]> { '[' <( <-[\]]>+ )> ']' }
token matcher​:sym<lit> { <-[/*?[]>+ }
}
class RuleCompiler {
# Simply commenting out this causes the matcher​:sym<lit> to get the
.txt it should. With
# this, it gets ].txt instead.
method matcher​:sym<[]>($/) { }
}
say Parser.parse('[AB].txt', :actions(RuleCompiler));

Commenting out the action method makes the final match tree correct.
Without it, the match tree ends up with the second matcher wrongly
capturing the ].

I've had trouble bisecting it due to unbuildable commits; the log is here​:

https://gist.github.com/Whateverable/119eb26d8ca245bf59ec05bc014c9fc2

It was fine in 2017.03 and broken in 2017.04, perhaps around the time of
the uncurse merge. I'm somewhat suspecting that, since it unified Match and
Cursor. This code may be a tricky edge case for the unification since it
uses the <( and )> constructs, which make the captured text and the text
matched by the cursor differ.

Fixed by TimToady++ and test added in S05-metasyntax/angle-brackets.t.

@p6rt
Copy link
Author

p6rt commented Apr 21, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Apr 21, 2017

@jnthn - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Apr 21, 2017
@p6rt p6rt added the regex Regular expressions, pattern matching, user-defined grammars, tokens and rules label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regex Regular expressions, pattern matching, user-defined grammars, tokens and rules
Projects
None yet
Development

No branches or pull requests

1 participant