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
Backtracking modifiers on individual atoms fail to override a regex-global :ratchet
modifier.
#6474
Comments
From @smlsBased on S05, these test-cases should all pass: is "ab" ~~ / [ab | a ] b /, "ab", 'normal backtracking'; In current Rakudo, the first three pass but the last one fails (it According to S05 that's a bug: "The new :r or :ratchet modifier causes this regex to not backtrack by Related to RT #130117. |
From @cokeOn Sun, 27 Aug 2017 10:03:52 -0700, smls75@gmail.com wrote:
At this stage, something's presence in one of the SYN doesn't mandate that it needs to be present in rakudo. Tagged ticket as RFC. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @smlsI sent a pull request to nqp that fixes this, please review: On Mon, 28 Aug 2017 05:53:36 -0700, coke wrote:
I'd say this particular issue is pretty clearly a fix for an unintended oversight/bug in Rakudo's implementation of the interaction between two existing features: 1) `:r` which controls backtracking for the rest of the lexical scope it's in. The reasonable way for these to interact, is for the the more general one (which also by necessity comes first in the source code) to be overridden by the more specific one (which also comes later in the source code). The opposite (current Rakudo behavior in the demonstrated edge case) makes no sense, because if combining the general and specific modifier has the same effect as just the general one on its own, then there is not point in combining them in the first place. (And indeed this is also why I don't expect any negative fallout from this change.) A third option would theoretically be possible: *Forbid* combining the two features altogether, i.e. throw an exception. But there would have to be a pretty un-obvious reason to choose this over option A, and if there was one, the S05 authors would have probably thought of it. My patch to fix this¹ also tracked the current behavior to a probable thinko in a nested logic expression. TL;DR: This shouldn't be fixed *because* S05 says so, S05 is merely supporting evidence for there not being some obscure reason to not consider this a bug when it looks, quacks, etc. like a bug. 1) Raku/nqp@ba165c8 |
From @smlsOn Mon, 28 Aug 2017 09:20:33 -0700, smls75@gmail.com wrote:
The PR was merged (and Rakudo's nqp version bumped). Marking the ticket TESTNEEDED. (Note that some possible tests are listed in the PR description!) |
@smls - Status changed from 'open' to 'resolved' |
From @smlsTests were added here: Raku/roast@65a762217 |
Migrated from rt.perl.org#131973 (status was 'resolved')
Searchable as RT131973$
The text was updated successfully, but these errors were encountered: