%{^CAPTURE_ALL} is %+, not %-. #16105
Comments
From @AbigailCreated by @Abigailperlvar states that %{^CAPTURE_ALL} is an alias to %-. #!/opt/perl/bin/perl use 5.026; use strict; "AB" =~ /(?<letter>A)(?<letter>B)/; use Data::Dumper; __END__ This issue is still present in blead. Perl Info |
From @jkeenanOn 08/09/2017 07:32 AM, Abigail wrote:
Is this just a documentation error or is the implementation itself wrong? |
|
The RT System itself - Status changed from 'new' to 'open' |
From @AbigailOn Wed, Aug 09, 2017 at 04:41:04AM -0700, James E Keenan via RT wrote:
The implemenation it wrong; %+ already has an alias, %{^CAPTURE}. Abigail |
From @jkeenanOn 08/09/2017 09:15 AM, Abigail wrote:
Will we have to have a deprecation cycle in order to correct this problem? (From what I understand, yes.) Thank you very much. |
From @demerphqOn 9 Aug 2017 15:00, "James E Keenan" <jkeenan@pobox.com> wrote: On 08/09/2017 09:15 AM, Abigail wrote:
Will we have to have a deprecation cycle in order to correct this problem? (From what I understand, yes.) No I don't think so. This was just a stupid oversight. The docs are correct My bad. Sorry about this. Yves Thank you very much. |
From @AbigailOn Thu, Aug 10, 2017 at 05:23:50AM -0700, yves orton via RT wrote:
I agree with Yves. It's new in 5.26.0. I haven't looked how it's implemented
Don't fret it. Stuff happens; I only found this issue when writing Abigail |
From @xsawyerxOn 08/12/2017 12:19 PM, Abigail wrote:
I agree. We already intend for it to provide a certain behavior based on |
From @khwilliamsonOn 08/13/2017 08:24 AM, Sawyer X wrote:
We have agreed in past releases that new features are eligible for |
From kent@setattr.netThis is a simple fix - I assume that _tie_it is used by core only and can rely on the name of GV. The patch also adds few tests for the named variables. |
From kent@setattr.netblead-capture_all.patchdiff --git a/ext/Tie-Hash-NamedCapture/NamedCapture.xs b/ext/Tie-Hash-NamedCapture/NamedCapture.xs
index 7eaae5614d..a607c10090 100644
--- a/ext/Tie-Hash-NamedCapture/NamedCapture.xs
+++ b/ext/Tie-Hash-NamedCapture/NamedCapture.xs
@@ -25,8 +25,11 @@ _tie_it(SV *sv)
GV * const gv = (GV *)sv;
HV * const hv = GvHVn(gv);
SV *rv = newSV_type(SVt_RV);
+ const char *gv_name = GvNAME(gv);
CODE:
- SvRV_set(rv, newSVuv(*GvNAME(gv) == '-' ? RXapif_ALL : RXapif_ONE));
+ SvRV_set(rv, newSVuv(
+ strEQ(gv_name, "-") || strEQ(gv_name, "\003APTURE_ALL")
+ ? RXapif_ALL : RXapif_ONE));
SvROK_on(rv);
sv_bless(rv, GvSTASH(CvGV(cv)));
diff --git a/ext/Tie-Hash-NamedCapture/t/tiehash.t b/ext/Tie-Hash-NamedCapture/t/tiehash.t
index 3ebc81ad68..962754085f 100644
--- a/ext/Tie-Hash-NamedCapture/t/tiehash.t
+++ b/ext/Tie-Hash-NamedCapture/t/tiehash.t
@@ -3,7 +3,12 @@ use strict;
use Test::More;
-my %hashes = ('+' => \%+, '-' => \%-);
+my %hashes = (
+ '+' => \%+,
+ '-' => \%-,
+ '{^CAPTURE}' => \%{^CAPTURE},
+ '{^CAPTURE_ALL}' => \%{^CAPTURE_ALL},
+);
foreach (['plus1'],
['minus1', all => 1],
@@ -20,12 +25,12 @@ foreach (['plus1'],
is("abcdef" =~ /(?<foo>[ab])*(?<bar>c)(?<foo>d)(?<bar>[ef]*)/, 1,
"We matched");
-foreach my $name (qw(+ plus1 plus2 plus3)) {
+foreach my $name (qw(+ {^CAPTURE} plus1 plus2 plus3)) {
my $hash = $hashes{$name};
is_deeply($hash, { foo => 'b', bar => 'c' }, "%$name is as expected");
}
-foreach my $name (qw(- minus1 minus2)) {
+foreach my $name (qw(- {^CAPTURE_ALL} minus1 minus2)) {
my $hash = $hashes{$name};
is_deeply($hash, { foo => [qw(b d)], bar => [qw(c ef)] },
"%$name is as expected");
|
From @jkeenanOn Fri, 22 Sep 2017 16:41:03 GMT, kent-perl@setattr.net wrote:
This patch is available for smoke testing in this branch: smoke-me/jkeenan/131867-capture-all Thank you very much. |
From @cpansproutOn Fri, 22 Sep 2017 09:41:03 -0700, kent-perl@setattr.net wrote:
I can confirm that only the core uses (is supposed to use) _tie_it. -- Father Chrysostomos |
From @haukexHi, Bump! Also, I'm confused by the source in gv.c (below), as it *looks* like %{^CAPTURE} is being aliased to %-, and %{^CAPTURE_ALL} to %+, even though according to the documentation, it should be the other way around. But when inspected (attached), *both* %{^CAPTURE} and %{^CAPTURE_ALL} look like %+ ... /* @{^CAPTURE} %{^CAPTURE} */ For more context: https://www.perlmonks.org/?node_id=11101258 Regards, |
From @haukex |
From [Unknown Contact. See original ticket]Hi, Bump! Also, I'm confused by the source in gv.c (below), as it *looks* like %{^CAPTURE} is being aliased to %-, and %{^CAPTURE_ALL} to %+, even though according to the documentation, it should be the other way around. But when inspected (attached), *both* %{^CAPTURE} and %{^CAPTURE_ALL} look like %+ ... /* @{^CAPTURE} %{^CAPTURE} */ For more context: https://www.perlmonks.org/?node_id=11101258 Regards, |
From @hvdsOn Wed, 12 Jun 2019 02:29:12 -0700, haukex@zero-g.net wrote:
Looks can be deceiving: the '-' or '+' in the second argument is there only for diagnostics and is not passed through to the function that does the actual tying, which uses the name found in the gv. The patch seems to have got dropped on the floor somehow - Jim, you mention a smoke branch, did that raise any concerns? Hugo |
From @jkeenanOn Wed, 12 Jun 2019 10:27:12 GMT, hv wrote:
http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2F131867-capture-all But we have much fewer smoke-testing back when the patch was submitted. So if we're going to do anything we should rebase the branch on blead and re-smoke. Let me know what you recommend. Thank you very much. -- |
From @hvdsOn Wed, 12 Jun 2019 05:00:45 -0700, jkeenan wrote:
Well we should do something, so let's do that. I'll also add it to various blockers tickets if I can find them, so we at least consider it for maintenance releases: it'd be a shame to have people start to use this correctly, and then find it does the wrong thing on some releases. Hugo |
From @jkeenanOn Wed, 12 Jun 2019 12:20:08 GMT, hv wrote:
Rebased and pushed.
-- |
From @haukexHi, I suspect this is related: As PerlMonks user vr noted (https://www.perlmonks.org/?node_id=11101258), in the following, swapping the two "dd" lines causes %{^CAPTURE} to show up as an empty, untied hash. Can this be fixed in the same fix as this bug, or should it be a new bug report? use Data::Dump; Thanks, |
From [Unknown Contact. See original ticket]Hi, I suspect this is related: As PerlMonks user vr noted (https://www.perlmonks.org/?node_id=11101258), in the following, swapping the two "dd" lines causes %{^CAPTURE} to show up as an empty, untied hash. Can this be fixed in the same fix as this bug, or should it be a new bug report? use Data::Dump; Thanks, |
From @haukexHi, On Wed, 12 Jun 2019 03:27:12 -0700, hv wrote:
Ah, thank you! So does that mean they'll be reported wrong in diagnostics? And I guess it would probably make sense to change them in any case? (I don't see the patch in this thread doing that.) Thanks, Regards, |
From @hvdsOn Wed, 12 Jun 2019 10:43:40 -0700, haukex@zero-g.net wrote:
That means if the internal require_tie_mod_s() call fails, it will refer to %- in the message. The call it is making accepts only a character here, not a string, so making it accept '^CAPTURE' would require a more extensive change (and it isn't obvious to me what other impact such a change might have). The diagnostics you might get would normally be possible only if your perl installation is broken, eg if the Tie::Hash::NamedCapture module cannot be loaded. Hugo |
From @hvdsOn Wed, 12 Jun 2019 10:35:13 -0700, haukex@zero-g.net wrote:
That appears to be a separate bug, I suggest filing a new bug report that shows the output you get in both cases (preferably using a core module such as Data::Dumper). At first glance, it looks like the implementation in gv_magicalize() is quite flawed: the docs say this function is called "when creating a new GV", so having the tie action be conditional on the svtype seems wrong. However there's similar logic in the handling of %+ (which doesn't suffer from the same problem), so I may be misunderstanding what's going on. Hugo |
From @haukexHi, On Wed, 12 Jun 2019 12:03:16 -0700, hv wrote:
Ok, but shouldn't at least the '+' and '-' be swapped? Thanks, |
From [Unknown Contact. See original ticket]Hi, On Wed, 12 Jun 2019 12:03:16 -0700, hv wrote:
Ok, but shouldn't at least the '+' and '-' be swapped? Thanks, |
From @haukexHi, On Wed, 12 Jun 2019 12:32:59 -0700, hv wrote:
Ok, thanks, done: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134193 Regards, |
From [Unknown Contact. See original ticket]Hi, On Wed, 12 Jun 2019 12:32:59 -0700, hv wrote:
Ok, thanks, done: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134193 Regards, |
From @tonycozOn Fri, 22 Sep 2017 09:41:03 -0700, kent-perl@setattr.net wrote:
Thanks, applied as 1a1d29a along with the patches for 134193. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
Migrated from rt.perl.org#131867 (status was 'pending release')
Searchable as RT131867$
The text was updated successfully, but these errors were encountered: