[Perl/perl5] df8581: Dynaloader: in XS avoid setting ST(0) in void XSUB
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: df8581b2ed4f95d0aeec6a25c1590ed27ed32437 https://github.com/Perl/perl5/commit/df8581b2ed4f95d0aeec6a25c1590ed27ed32437 Author: David Mitchell Date: 2024-08-02 (Fri, 02 Aug 2024) Changed paths: M ext/DynaLoader/DynaLoader_pm.PL M ext/DynaLoader/dl_dlopen.xs Log Message: --- Dynaloader: in XS avoid setting ST(0) in void XSUB A historical quirk of XS, which was fixed in 1996, allowed code along the lines of: void foo(...) CODE: ... ST(0) = ...; This is wrong, because the code is declared as returning nothing, but still puts something on the stack. xsubpp has hacky logic to work around this. Normally it would emit 'XSRETURN_EMPTY', but if it sees text like 'ST(n) = ' in the body of an XSUB, it emits 'XSRETURN(1)' instead. The docs were fixed in 1996, but this anti-pattern continues to reproduce. Eventually I want to make xsubpp emit a warning if it has to apply this hack, but in the meantime, this commit is the start of an effort to eliminate this code style. This change shouldn't affect functionality. Note that this commit only updates the xs file which is used on my Linux system. There are bunch of other OS-specific variant .xs files such as dl_win32.xs, which I haven't attempted to fix up as I can't test the result. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 454f2c: Dynaloader: in XS avoid setting ST(0) in void XSUB
Branch: refs/heads/davem/st0_hack Home: https://github.com/Perl/perl5 Commit: 454f2c1975a58821824e2c137f9d4091f4ec2a1f https://github.com/Perl/perl5/commit/454f2c1975a58821824e2c137f9d4091f4ec2a1f Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M ext/DynaLoader/DynaLoader_pm.PL M ext/DynaLoader/dl_dlopen.xs Log Message: --- Dynaloader: in XS avoid setting ST(0) in void XSUB A historical quirk of XS, which was fixed in 1996, allowed code along the lines of: void foo(...) CODE: ... ST(0) = ...; This is wrong, because the code is declared as returning nothing, but still puts something on the stack. xsubpp has hacky logic to work around this. Normally it would emit 'XSRETURN_EMPTY', but if it sees text like 'ST(n) = ' in the body of an XSUB, it emits 'XSRETURN(1)' instead. The docs were fixed in 1996, but this anti-pattern continues to reproduce. Eventually I want to make xsubpp emit a warning if it has to apply this hack, but in the meantime, this commit is the start of an effort to eliminate this code style. This change shouldn't affect functionality. Note that this commit only updates the xs file which is used on my Linux system. There are bunch of other OS-specific variant .xs files such as dl_win32.xs, which I haven't attempted to fix up as I can't test the result. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 18a602: bump ExtUtils::ParseXS versions to 3.53
Branch: refs/heads/davem/xscomments Home: https://github.com/Perl/perl5 Commit: 18a602866084154d4f29f84d70a468c7b7e8fb7f https://github.com/Perl/perl5/commit/18a602866084154d4f29f84d70a468c7b7e8fb7f Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Constants.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/CountLines.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Eval.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Cmd.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/InputMap.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Type.pm M dist/ExtUtils-ParseXS/lib/perlxs.pod Log Message: --- bump ExtUtils::ParseXS versions to 3.53 Commit: bd9fc9f5f769b710a53e30d089c39871abeb1e5b https://github.com/Perl/perl5/commit/bd9fc9f5f769b710a53e30d089c39871abeb1e5b Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M MANIFEST Log Message: --- MANIFEST: point out XS-Typemap isn't installed It's easy to confuse these two: XS::Typemap ExtUtils::Typemaps Update the description of the XS::Typemap files in MANIFEST to aid in deconfusion. Commit: 1f63227b105f69097978fecd9dd8eb1bbfe34bde https://github.com/Perl/perl5/commit/1f63227b105f69097978fecd9dd8eb1bbfe34bde Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M lib/ExtUtils/typemap Log Message: --- lib/ExtUtils/typemap: add some comments Add a few lines to the top of this file explaining what its purpose is. Commit: 42944d3208f1fd7d11c54cd8d8e6518d54256d8b https://github.com/Perl/perl5/commit/42944d3208f1fd7d11c54cd8d8e6518d54256d8b Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M MANIFEST M Porting/exec-bit.txt A dist/ExtUtils-ParseXS/author/mksnapshot.pl Log Message: --- ExtUtils-ParseXS: add author/mksnapshot.pl utility Crude tool to collect before and after snapshots of all .c files created by xsubpp, in order to see what (if anything) has changed in functionality while working on ParseXS files. Commit: af7f95477403a3800e85cfecf0c968aa35fd5bd6 https://github.com/Perl/perl5/commit/af7f95477403a3800e85cfecf0c968aa35fd5bd6 Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm Log Message: --- ExtUtils::ParseXS: update pod for error handling Consolidate the POD for the various warning- and error-raising methods into a single block of text, to give a better overview of which method should be used when (e.g. warning vs deferred errors vs die immediately) The diff looks confusing, but its basically deleting the individual chunk of pod directly above each method, then adding a complete new block of pod. This contains completely new text, rather than copying and pasting. Commit: ddfb8338d7d16ce48721f0d9cef7fe20645c27c8 https://github.com/Perl/perl5/commit/ddfb8338d7d16ce48721f0d9cef7fe20645c27c8 Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Constants.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps.pm Log Message: --- Extutils::ParseXS *.pm: add many code comments To aid the understanding of this module and its sub-modules: - add lots of code comments - add blank lines - reformat and/or line-wrap a few long code lines There should be no functional changes. In particular, the line count of ParseXS.pm is increased by about 60% with this commit. I've tried to consistently use the word 'emit' rather than 'print' or 'output' in comments about the code that gets generated and ends up in the .c file. At the moment most of this code code is indeed just immediately printed to STDOUT, but in the longer term I would like to separate out code generation and output stages. Compare: https://github.com/Perl/perl5/compare/7244f6488fd0...ddfb8338d7d1 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 918f48: t/porting/libperl.t: add better diagnostics
Branch: refs/heads/davem/libperl Home: https://github.com/Perl/perl5 Commit: 918f480990c5947a8e7fd42153521c347daea309 https://github.com/Perl/perl5/commit/918f480990c5947a8e7fd42153521c347daea309 Author: David Mitchell Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: M t/porting/libperl.t Log Message: --- t/porting/libperl.t: add better diagnostics If it fails to find a symbol where expected (e.g. in the text section of the object file), then print a diagnostic message which lists all the nm lines where the symbol *was* found (if any). This is achieved by adding a xref hash which maps symbol names to arrays of lines / object files. Also document the format of the %symbols hash. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] ddf056: t/porting/libperl.t: add better diagnostics
Branch: refs/heads/davem/libperl Home: https://github.com/Perl/perl5 Commit: ddf056bb3b02caf1880bf71d63e8ad16f0fcebf4 https://github.com/Perl/perl5/commit/ddf056bb3b02caf1880bf71d63e8ad16f0fcebf4 Author: David Mitchell Date: 2024-07-31 (Wed, 31 Jul 2024) Changed paths: M t/porting/libperl.t Log Message: --- t/porting/libperl.t: add better diagnostics If it fails to find a symbol where expected (e.g. in the text section of the object file), then print a diagnostic message which lists all the nm lines where the symbol *was* found (if any). This is achieved by adding a xref hash which maps symbol names to arrays of lines / object files. Also document the format of the %symbols hash. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 70a7d0: t/porting/libperl.t: add better diagnostics
Branch: refs/heads/davem/libperl Home: https://github.com/Perl/perl5 Commit: 70a7d0c5ab4a33fccf3ffb7d45ca80de06a40aed https://github.com/Perl/perl5/commit/70a7d0c5ab4a33fccf3ffb7d45ca80de06a40aed Author: David Mitchell Date: 2024-07-30 (Tue, 30 Jul 2024) Changed paths: M t/porting/libperl.t Log Message: --- t/porting/libperl.t: add better diagnostics If it fails to find a symbol where expected (e.g. in the text section of the object file), then print a diagnostic message which lists all the nm lines where the symbol *was* found (if any). This is achieved by adding a xref hash which maps symbol names to arrays of lines / object files. Also document the format of the %symbols hash. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] c75226: bump ExtUtils::ParseXS versions to 3.53
Branch: refs/heads/davem/xscomments Home: https://github.com/Perl/perl5 Commit: c752269e22e4a9b897c9c64f83cf6e28f26e3e37 https://github.com/Perl/perl5/commit/c752269e22e4a9b897c9c64f83cf6e28f26e3e37 Author: David Mitchell Date: 2024-07-29 (Mon, 29 Jul 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Constants.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/CountLines.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Eval.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Cmd.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/InputMap.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Type.pm M dist/ExtUtils-ParseXS/lib/perlxs.pod Log Message: --- bump ExtUtils::ParseXS versions to 3.53 Commit: ec1b011f41a093a579b266b2b65d810b7e59d336 https://github.com/Perl/perl5/commit/ec1b011f41a093a579b266b2b65d810b7e59d336 Author: David Mitchell Date: 2024-07-29 (Mon, 29 Jul 2024) Changed paths: M MANIFEST Log Message: --- MANIFEST: point out XS-Typemap isn't installed It's easy to confuse these two: XS::Typemap ExtUtils::Typemaps Update the description of the XS::Typemap files in MANIFEST to aid in deconfusion. Commit: 24382a39ec2f9d9028f50ff4780e1726eab0d94c https://github.com/Perl/perl5/commit/24382a39ec2f9d9028f50ff4780e1726eab0d94c Author: David Mitchell Date: 2024-07-29 (Mon, 29 Jul 2024) Changed paths: M lib/ExtUtils/typemap Log Message: --- lib/ExtUtils/typemap: add some comments Add a few lines to the top of this file explaining what its purpose is. Commit: fee5e5b933aa4792bf576f1657f015df25bf4cc7 https://github.com/Perl/perl5/commit/fee5e5b933aa4792bf576f1657f015df25bf4cc7 Author: David Mitchell Date: 2024-07-29 (Mon, 29 Jul 2024) Changed paths: M MANIFEST M Porting/exec-bit.txt A dist/ExtUtils-ParseXS/author/mksnapshot.pl Log Message: --- ExtUtils-ParseXS: add author/mksnapshot.pl utility Crude tool to collect before and after snapshots of all .c files created by xsubpp, in order to see what (if anything) has changed in functionality while working on ParseXS files. Commit: 339e005a3a31e47da916b678dbca0a2949ae9ed2 https://github.com/Perl/perl5/commit/339e005a3a31e47da916b678dbca0a2949ae9ed2 Author: David Mitchell Date: 2024-07-29 (Mon, 29 Jul 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm Log Message: --- ExtUtils::ParseXS: update pod for error handling Consolidate the POD for the various warning- and error-raising methods into a single block of text, to give a better overview of which method should be used when (e.g. warning vs deferred errors vs die immediately) The diff looks confusing, but its basically deleting the individual chunk of pod directly above each method, then adding a complete new block of pod. This contains completely new text, rather than copying and pasting. Commit: 7244f6488fd013b68fa490990ed15515c8a64289 https://github.com/Perl/perl5/commit/7244f6488fd013b68fa490990ed15515c8a64289 Author: David Mitchell Date: 2024-07-30 (Tue, 30 Jul 2024) Changed paths: M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Constants.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps.pm Log Message: --- Extutils::ParseXS *.pm: add many code comments To aid the understanding of this module and its sub-modules: - add lots of code comments - add blank lines - reformat and/or line-wrap a few long code lines There should be no functional changes. In particular, the line count of ParseXS.pm is increased by about 60% with this commit. I've tried to consistently use the word 'emit' rather than 'print' or 'output' in comments about the code that gets generated and ends up in the .c file. At the moment most of this code code is indeed just immediately printed to STDOUT, but in the longer term I would like to separate out code generation and output stages. Compare: https://github.com/Perl/perl5/compare/c752269e22e4%5E...7244f6488fd0 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/padsv_store Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 9a224d: OP_PADSV_STORE: only in void context
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 9a224d076a17344e9e851460223544deb2a30532
https://github.com/Perl/perl5/commit/9a224d076a17344e9e851460223544deb2a30532
Author: David Mitchell
Date: 2024-06-19 (Wed, 19 Jun 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M peep.c
M pp_hot.c
M t/perf/opcount.t
Log Message:
---
OP_PADSV_STORE: only in void context
(The original commit, v5.39.6-108-gc90e7ed39e, was reverted by
v5.39.8-35-gdc524b6cbd, and is now being re-applied. Originally it broke
some CPAN distributions and as it was near code-freeze time and was only
an optimisation, it seemed better to leave it for later. Since we're now
early in the cycle of 5.41.x, there's more time to fix up any fallout.)
For the optimisation which converts $lex = expr into an OP_PADSV_STORE
op, only optimise if the scalar assign is in VOID context.
This allows us to stop pp_padsv_store() from uselessly pushing the
result onto the stack, only to be immediately popped again by the
following nextstate or unstack op. This becomes more important on
PERL_RC_STACK builds, as each push or pop involves manipulating the SV's
reference count.
I'm working on the assumption that scalar/list/unknown cxt lexical
assigns are rare enough that not optimising them is less of a loss than
optimising the void case. So:
$lex = ; # void:now even faster
$other = $lex = ...; # scalar: now slow again
foo($lex = ..., ); # list:now slow again
sub {
$lex = ...; # unknown: now slow again
}
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 6c77c0: OP_PADSV_STORE: only in void context
Branch: refs/heads/davem/padsv_store
Home: https://github.com/Perl/perl5
Commit: 6c77c095ba2add4b74b70cdbc54c76338152cda8
https://github.com/Perl/perl5/commit/6c77c095ba2add4b74b70cdbc54c76338152cda8
Author: David Mitchell
Date: 2024-06-19 (Wed, 19 Jun 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M peep.c
M pp_hot.c
M t/perf/opcount.t
Log Message:
---
OP_PADSV_STORE: only in void context
(The original commit, v5.39.6-108-gc90e7ed39e, was reverted by
v5.39.8-35-gdc524b6cbd, and is now being re-applied. Originally it broke
some CPAN distributions and as it was near code-freeze time and was only
an optimisation, it seemed better to leave it for later. Since we're now
early in the cycle of 5.41.x, there's more time to fix up any fallout.)
For the optimisation which converts $lex = expr into an OP_PADSV_STORE
op, only optimise if the scalar assign is in VOID context.
This allows us to stop pp_padsv_store() from uselessly pushing the
result onto the stack, only to be immediately popped again by the
following nextstate or unstack op. This becomes more important on
PERL_RC_STACK builds, as each push or pop involves manipulating the SV's
reference count.
I'm working on the assumption that scalar/list/unknown cxt lexical
assigns are rare enough that not optimising them is less of a loss than
optimising the void case. So:
$lex = ; # void:now even faster
$other = $lex = ...; # scalar: now slow again
foo($lex = ..., ); # list:now slow again
sub {
$lex = ...; # unknown: now slow again
}
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/rx_codeblocks2 Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 40727c: pat codeblocks: add size to struct reg_code_blocks
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 40727c420c8e9ed61971dd46fc738132b9e4d5db
https://github.com/Perl/perl5/commit/40727c420c8e9ed61971dd46fc738132b9e4d5db
Author: David Mitchell
Date: 2024-06-18 (Tue, 18 Jun 2024)
Changed paths:
M regcomp.c
M regexp.h
M t/re/pat.t
Log Message:
---
pat codeblocks: add size to struct reg_code_blocks
Split the 'count' field of reg_code_blocks structures into separate
'count' and 'size' fields to make the code less fragile; and as an
intended side-effect, fix GH #16627.
Background:
When a pattern includes embedded perl code, such as /(?{ CODE })/, then
at compile-time the op trees associated with each of those code blocks
are stored within the compiled regex, in a reg_code_blocks structure.
This structure contains some basic info, plus a pointer to an array of
reg_code_block structures, each of which contains a pointer to the
optree for that code block, plus string offsets to where the (?{..}) or
similar expression starts and ends within the pattern string.
For a runtime pattern, perl tries to reuse any original compiled code
blocks rather than recompiling them, to maintain correct closure
behaviour.
So for example, consider the following:
my $x = 1;
{ my $x = 2; $r = qr/(??{$x})/ }
my $y = 3;
my $s = '(??{$y})';
my $pat = qr/A (??{$x}) B $r C $s/x;
At perl compile time, the two '$x' code blocks are compiled, and their
optrees stored.
At runtime, when the $pat pattern is compiled, the third code block,
'$y', is compiled, and the two earlier optrees are retrieved. A new
three-element 'struct reg_code_block' array is malloc()ed, and the
pointers to the two old, and one new, optrees are stored in it.
So when $pat gets compiled, it becomes equivalent to:
qr/A (??{$x}) B (??{$x}) C (??{$y})/x;
except that the $x's have different values since they are from different
closures. When the pattern is executed, the sub-patterns returned by the
various (??{..})'s result in $pat having the same overall effect as
qr/A1B2C3/.
The assembly of this reg_code_block array is mostly performed by
S_concat_pat() and S_compile_runtime_code(). It is done incrementally,
since the total number of code blocks isn't known in advance.
Prior to this commit, the array was often realloced() and grown one
element at a time as each new run-time code block was discovered, with
a corresponding pRExC_state->code_blocks->count++.
This count field served twin purposes: it indicated both how many code
blocks had been found and stored so far, and the malloc()ed size of the
array. But some parts of the regex compiler allocate more than one slot
at a time, and so the two meanings of the 'count' field temporarily
diverge. This became noticeable when S_concat_pat() recursed to
interpolate the contents of an array, such as qr/$a$b@c/, where
interpolating $a, $b was done iteratively at the top level, then it
recursed to process each element of @c. S_concat_pat() had a local var,
'int n', which counted how many code blocks had been found so far, and
this value sometimes represented the difference between the two meanings
of the 'count' field.
However when it recursed, n started from zero again and things got out
of whack, which led to GH #16627. The bug in that ticket can be reduced
to:
my @x = ( qr/(?{A})/ );
qr/(?{B})@x/;
Here the B code block is stored in pRExC_state->code_blocks->cb[0],
but then S_concat_pat() recurses, n is reset to 0, and the A code block
is also stored into slot 0. Then things would start to crash.
The quick and dirty fix would be to share n between recursive calls to
S_concat_pat(), by passing a pointer to it. Instead, this commit takes
the approach of adding a 'size' field to pRExC_state->code_blocks,
so that ->count now only indicates the current number of code blocks
stored (replacing the local var n) while ->size indicates the current
number of slots malloc()ed.
This makes the code more conventional and simpler to understand, and
allows the realloc() to pre-allocate rather than incrementing the array
size by 1 each time. By removing the fragile double meaning of the
'count' field, it should make any future bugs easier to diagnose, at the
cost of this initial commit being more complex.
Commit: f4099afb471a193e2110fd696d50acd06ac3c4bb
https://github.com/Perl/perl5/commit/f4099afb471a193e2110fd696d50acd06ac3c4bb
Author: David Mitchell
Date: 2024-06-18 (Tue, 18 Jun 2024)
Changed paths:
M regcomp.c
M t/op/svleak.t
Log Message:
---
avoid leak in regex with overload and code block
When concatenating the components of a run-time pattern, if
a component has concat overloading, then that method is used, and
any previously accumulated code blocks - i.e. (?{...}) and similar -
are discarded. However, the ref counts of of any regex objects
pointed to which contained those code block(s) weren't having
their reference count decremen
[Perl/perl5] 40727c: pat codeblocks: add size to struct reg_code_blocks
Branch: refs/heads/davem/rx_codeblocks2
Home: https://github.com/Perl/perl5
Commit: 40727c420c8e9ed61971dd46fc738132b9e4d5db
https://github.com/Perl/perl5/commit/40727c420c8e9ed61971dd46fc738132b9e4d5db
Author: David Mitchell
Date: 2024-06-18 (Tue, 18 Jun 2024)
Changed paths:
M regcomp.c
M regexp.h
M t/re/pat.t
Log Message:
---
pat codeblocks: add size to struct reg_code_blocks
Split the 'count' field of reg_code_blocks structures into separate
'count' and 'size' fields to make the code less fragile; and as an
intended side-effect, fix GH #16627.
Background:
When a pattern includes embedded perl code, such as /(?{ CODE })/, then
at compile-time the op trees associated with each of those code blocks
are stored within the compiled regex, in a reg_code_blocks structure.
This structure contains some basic info, plus a pointer to an array of
reg_code_block structures, each of which contains a pointer to the
optree for that code block, plus string offsets to where the (?{..}) or
similar expression starts and ends within the pattern string.
For a runtime pattern, perl tries to reuse any original compiled code
blocks rather than recompiling them, to maintain correct closure
behaviour.
So for example, consider the following:
my $x = 1;
{ my $x = 2; $r = qr/(??{$x})/ }
my $y = 3;
my $s = '(??{$y})';
my $pat = qr/A (??{$x}) B $r C $s/x;
At perl compile time, the two '$x' code blocks are compiled, and their
optrees stored.
At runtime, when the $pat pattern is compiled, the third code block,
'$y', is compiled, and the two earlier optrees are retrieved. A new
three-element 'struct reg_code_block' array is malloc()ed, and the
pointers to the two old, and one new, optrees are stored in it.
So when $pat gets compiled, it becomes equivalent to:
qr/A (??{$x}) B (??{$x}) C (??{$y})/x;
except that the $x's have different values since they are from different
closures. When the pattern is executed, the sub-patterns returned by the
various (??{..})'s result in $pat having the same overall effect as
qr/A1B2C3/.
The assembly of this reg_code_block array is mostly performed by
S_concat_pat() and S_compile_runtime_code(). It is done incrementally,
since the total number of code blocks isn't known in advance.
Prior to this commit, the array was often realloced() and grown one
element at a time as each new run-time code block was discovered, with
a corresponding pRExC_state->code_blocks->count++.
This count field served twin purposes: it indicated both how many code
blocks had been found and stored so far, and the malloc()ed size of the
array. But some parts of the regex compiler allocate more than one slot
at a time, and so the two meanings of the 'count' field temporarily
diverge. This became noticeable when S_concat_pat() recursed to
interpolate the contents of an array, such as qr/$a$b@c/, where
interpolating $a, $b was done iteratively at the top level, then it
recursed to process each element of @c. S_concat_pat() had a local var,
'int n', which counted how many code blocks had been found so far, and
this value sometimes represented the difference between the two meanings
of the 'count' field.
However when it recursed, n started from zero again and things got out
of whack, which led to GH #16627. The bug in that ticket can be reduced
to:
my @x = ( qr/(?{A})/ );
qr/(?{B})@x/;
Here the B code block is stored in pRExC_state->code_blocks->cb[0],
but then S_concat_pat() recurses, n is reset to 0, and the A code block
is also stored into slot 0. Then things would start to crash.
The quick and dirty fix would be to share n between recursive calls to
S_concat_pat(), by passing a pointer to it. Instead, this commit takes
the approach of adding a 'size' field to pRExC_state->code_blocks,
so that ->count now only indicates the current number of code blocks
stored (replacing the local var n) while ->size indicates the current
number of slots malloc()ed.
This makes the code more conventional and simpler to understand, and
allows the realloc() to pre-allocate rather than incrementing the array
size by 1 each time. By removing the fragile double meaning of the
'count' field, it should make any future bugs easier to diagnose, at the
cost of this initial commit being more complex.
Commit: f4099afb471a193e2110fd696d50acd06ac3c4bb
https://github.com/Perl/perl5/commit/f4099afb471a193e2110fd696d50acd06ac3c4bb
Author: David Mitchell
Date: 2024-06-18 (Tue, 18 Jun 2024)
Changed paths:
M regcomp.c
M t/op/svleak.t
Log Message:
---
avoid leak in regex with overload and code block
When concatenating the components of a run-time pattern, if
a component has concat overloading, then that method is used, and
any previously accumulated code blocks - i.e. (?{...}) and similar -
are discarded. However, the ref counts of of any regex objects
pointed to which contained those code block(s) weren't having
their reference
[Perl/perl5]
Branch: refs/heads/davem/eval_compiled Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] d06d71: add CvEVAL_COMPILED() flag and fix closure bug.
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: d06d7106c2a33ff04a79463396bd9139f41380e3 https://github.com/Perl/perl5/commit/d06d7106c2a33ff04a79463396bd9139f41380e3 Author: David Mitchell Date: 2024-06-17 (Mon, 17 Jun 2024) Changed paths: M cv.h M dump.c M op.c M pad.c M t/op/eval.t Log Message: --- add CvEVAL_COMPILED() flag and fix closure bug. EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields don't get populated; instead the current values are stored in the PL_eval_root and PL_eval_start variables while they are being executed. This caused a bug in closures and nested evals when an inner eval was repeated twice. The first inner eval accessed an outer lexical, which caused a fake cache entry to be added to the outer eval's pad. The second inner eval finds this cached entry, but incorrectly concludes that the outer eval is in fact an anon sub prototype and issues a 'variable is not available' warning. This is due to this simplistic definition in pad.c: #define CvCOMPILED(cv) CvROOT(cv) This commit adds a new flag, CvEVAL_COMPILED(), to indicate a fully-compiled EVAL CV. This allows us to work around the limitation. In an ideal world this would have been fixed instead by making EVAL CVs first-class citizens with CvROOT() etc, but plenty of stuff seems to assume otherwise. So I took the path of least resistance. See https://www.perlmonks.org/?node_id=11158351 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] d06d71: add CvEVAL_COMPILED() flag and fix closure bug.
Branch: refs/heads/davem/eval_compiled Home: https://github.com/Perl/perl5 Commit: d06d7106c2a33ff04a79463396bd9139f41380e3 https://github.com/Perl/perl5/commit/d06d7106c2a33ff04a79463396bd9139f41380e3 Author: David Mitchell Date: 2024-06-17 (Mon, 17 Jun 2024) Changed paths: M cv.h M dump.c M op.c M pad.c M t/op/eval.t Log Message: --- add CvEVAL_COMPILED() flag and fix closure bug. EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields don't get populated; instead the current values are stored in the PL_eval_root and PL_eval_start variables while they are being executed. This caused a bug in closures and nested evals when an inner eval was repeated twice. The first inner eval accessed an outer lexical, which caused a fake cache entry to be added to the outer eval's pad. The second inner eval finds this cached entry, but incorrectly concludes that the outer eval is in fact an anon sub prototype and issues a 'variable is not available' warning. This is due to this simplistic definition in pad.c: #define CvCOMPILED(cv) CvROOT(cv) This commit adds a new flag, CvEVAL_COMPILED(), to indicate a fully-compiled EVAL CV. This allows us to work around the limitation. In an ideal world this would have been fixed instead by making EVAL CVs first-class citizens with CvROOT() etc, but plenty of stuff seems to assume otherwise. So I took the path of least resistance. See https://www.perlmonks.org/?node_id=11158351 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 511341: add CvEVAL_COMPILED() flag and fix closure bug.
Branch: refs/heads/smoke-me/jkeenan/davem/eval-compiled-gh-22097-20240610 Home: https://github.com/Perl/perl5 Commit: 511341e827e85b91ff667d2644832a1847f9cda4 https://github.com/Perl/perl5/commit/511341e827e85b91ff667d2644832a1847f9cda4 Author: David Mitchell Date: 2024-06-10 (Mon, 10 Jun 2024) Changed paths: M cv.h M dump.c M op.c M pad.c M t/op/eval.t Log Message: --- add CvEVAL_COMPILED() flag and fix closure bug. EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields don't get populated; instead the current values are stored in the PL_eval_root and PL_eval_start variables while they are being executed. This caused a bug in closures and nested evals when an inner eval was repeated twice. The first inner eval accessed an outer lexical, which caused a fake cache entry to be added to the outer eval's pad. The second inner eval finds this cached entry, but incorrectly concludes that the outer eval is in fact an anon sub prototype and issues a 'variable is not available' warning. This is due to this simplistic definition in pad.c: #define CvCOMPILED(cv) CvROOT(cv) This commit adds a new flag, CvEVAL_COMPILED(), to indicate a fully-compiled EVAL CV. This allows us to work around the limitation. In an ideal world this would have been fixed instead by making EVAL CVs first-class citizens with CvROOT() etc, but plenty of stuff seems to assume otherwise. So I took the path of least resistance. See https://www.perlmonks.org/?node_id=11158351 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 121cb4: perldelta: fix 'perlguts for PERL_RC_STACK' entry
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 121cb45e8f6c507d1bac1c67fc71be0dbda02c18 https://github.com/Perl/perl5/commit/121cb45e8f6c507d1bac1c67fc71be0dbda02c18 Author: David Mitchell Date: 2024-05-31 (Fri, 31 May 2024) Changed paths: M pod/perldelta.pod Log Message: --- perldelta: fix 'perlguts for PERL_RC_STACK' entry The original entry was copied from 5.39.something's perldelta, and just mentioned some more rpp_ functions being added to perlguts. But *all* rpp_ function are new to 5.40.0, not just those extra ones. So make the entry in perldelta more generic. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 827b07: pat codeblocks: add size to struct reg_code_blocks
Branch: refs/heads/davem/rx_codeblocks2
Home: https://github.com/Perl/perl5
Commit: 827b074904fa723ad8ba36f6b65d1718aca2add9
https://github.com/Perl/perl5/commit/827b074904fa723ad8ba36f6b65d1718aca2add9
Author: David Mitchell
Date: 2024-05-20 (Mon, 20 May 2024)
Changed paths:
M regcomp.c
M regexp.h
M t/re/pat.t
Log Message:
---
pat codeblocks: add size to struct reg_code_blocks
Split the 'count' field of reg_code_blocks structures into separate
'count' and 'size' fields to make the code less fragile; and as an
intended side-effect, fix GH #16627.
Background:
When a pattern includes embedded perl code, such as /(?{ CODE })/, then
at compile-time the op trees associated with each of those code blocks
are stored within the compiled regex, in a reg_code_blocks structure.
This structure contains some basic info, plus a pointer to an array of
reg_code_block structures, each of which contains a pointer to the
optree for that code block, plus string offsets to where the (?{..}) or
similar expression starts and ends within the pattern string.
For a runtime pattern, perl tries to reuse any original compiled code
blocks rather than recompiling them, to maintain correct closure
behaviour.
So for example, consider the following:
my $x = 1;
{ my $x = 2; $r = qr/(??{$x})/ }
my $y = 3;
my $s = '(??{$y})';
my $pat = qr/A (??{$x}) B $r C $s/x;
At perl compile time, the two '$x' code blocks are compiled, and their
optrees stored.
At runtime, when the $pat pattern is compiled, the third code block,
'$y', is compiled, and the two earlier optrees are retrieved. A new
three-element 'struct reg_code_block' array is malloc()ed, and the
pointers to the two old, and one new, optrees are stored in it.
So when $pat gets compiled, it becomes equivalent to:
qr/A (??{$x}) B (??{$x}) C (??{$y})/x;
except that the $x's have different values since they are from different
closures. When the pattern is executed, the sub-patterns returned by the
various (??{..})'s result in $pat having the same overall effect as
qr/A1B2C3/.
The assembly of this reg_code_block array is mostly performed by
S_concat_pat() and S_compile_runtime_code(). It is done incrementally,
since the total number of code blocks isn't known in advance.
Prior to this commit, the array was often realloced() and grown one
element at a time as each new run-time code block was discovered, with
a corresponding pRExC_state->code_blocks->count++.
This count field served twin purposes: it indicated both how many code
blocks had been found and stored so far, and the malloc()ed size of the
array. But some parts of the regex compiler allocate more than one slot
at a time, and so the two meanings of the 'count' field temporarily
diverge. This became noticeable when S_concat_pat() recursed to
interpolate the contents of an array, such as qr/$a$b@c/, where
interpolating $a, $b was done iteratively at the top level, then it
recursed to process each element of @c. S_concat_pat() had a local var,
'int n', which counted how many code blocks had been found so far, and
this value sometimes represented the difference between the two meanings
of the 'count' field.
However when it recursed, n started from zero again and things got out
of whack, which led to GH #16627. The bug in that ticket can be reduced
to:
my @x = ( qr/(?{A})/ );
qr/(?{B})@x/;
Here the B code block is stored in pRExC_state->code_blocks->cb[0],
but then S_concat_pat() recurses, n is reset to 0, and the A code block
is also stored into slot 0. Then things would start to crash.
The quick and dirty fix would be to share n between recursive calls to
S_concat_pat(), by passing a pointer to it. Instead, this commit takes
the approach of adding a 'size' field to pRExC_state->code_blocks,
so that ->count now only indicates the current number of code blocks
stored (replacing the local var n) while ->size indicates the current
number of slots malloc()ed.
This makes the code more conventional and simpler to understand, and
allows the realloc() to pre-allocate rather than incrementing the array
size by 1 each time. By removing the fragile double meaning of the
'count' field, it should make any future bugs easier to diagnose, at the
cost of this initial commit being more complex.
Commit: 436f01a330bc451e0e67b5fd38b15805cf63c08c
https://github.com/Perl/perl5/commit/436f01a330bc451e0e67b5fd38b15805cf63c08c
Author: David Mitchell
Date: 2024-05-20 (Mon, 20 May 2024)
Changed paths:
M regcomp.c
M t/op/svleak.t
Log Message:
---
avoid leak in regex with overload and code block
When concatenating the components of a run-time pattern, if
a component has concat overloading, then that method is used, and
any previously accumulated code blocks - i.e. (?{...}) and similar -
are discarded. However, the ref counts of of any regex objects
pointed to which contained those code block(s) weren't having
their reference
[Perl/perl5]
Branch: refs/heads/davem/rc_delta Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] d16fb3: perldelta: add PERL_RC_STACK
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: d16fb3cef2b14d087101a5dac7e98bea23344dd8 https://github.com/Perl/perl5/commit/d16fb3cef2b14d087101a5dac7e98bea23344dd8 Author: David Mitchell Date: 2024-05-18 (Sat, 18 May 2024) Changed paths: M pod/perldelta.pod Log Message: --- perldelta: add PERL_RC_STACK This is a final summary of the state of the new ref-counted stack facility at the 5.40.0 release: and is intended to be added to the 5.40.0 perldelta, to replace (rather than than be in addition to) any earlier mentions of PERL_RC_STACK in the 5.39.2 and .6 perldeltas. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] e9d23e: perldelta: add PERL_RC_STACK
Branch: refs/heads/davem/rc_delta Home: https://github.com/Perl/perl5 Commit: e9d23e8f7a66819aeaf3d526937beb5610da5f2d https://github.com/Perl/perl5/commit/e9d23e8f7a66819aeaf3d526937beb5610da5f2d Author: David Mitchell Date: 2024-05-17 (Fri, 17 May 2024) Changed paths: M pod/perldelta.pod Log Message: --- perldelta: add PERL_RC_STACK This is a final summary of the state of the new ref-counted stack facility at the 5.40.0 release: and is intended to be added to the 5.40.0 perldelta, to replace (rather than than be in addition to) any earlier mentions of PERL_RC_STACK in the 5.39.2 and .6 perldeltas. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] b74d82: pat codeblocks: add size to struct reg_code_blocks
Branch: refs/heads/davem/rx_codeblocks2
Home: https://github.com/Perl/perl5
Commit: b74d82c334268af2b0eebaf2c73435f73e766a11
https://github.com/Perl/perl5/commit/b74d82c334268af2b0eebaf2c73435f73e766a11
Author: David Mitchell
Date: 2024-05-08 (Wed, 08 May 2024)
Changed paths:
M regcomp.c
M regexp.h
M t/re/pat.t
Log Message:
---
pat codeblocks: add size to struct reg_code_blocks
Split the 'count' field of reg_code_blocks structures into separate
'count' and 'size' fields to make the code less fragile; and as an
intended side-effect, fix GH #16627.
Background:
When a pattern includes embedded perl code, such as /(?{ CODE })/, then
at compile-time the op trees associated with each of those code blocks
are stored within the compiled regex, in a reg_code_blocks structure.
This structure contains some basic info, plus a pointer to an array of
reg_code_block structures, each of which contains a pointer to the
optree for that code block, plus string offsets to where the (?{..}) or
similar expression starts and ends within the pattern string.
For a runtime pattern, perl tries to reuse any original compiled code
blocks rather than recompiling them, to maintain correct closure
behaviour.
So for example, in the following:
my $x = 1;
{ my $x = 2; $r = qr/(??{$x})/ }
my $y = 3;
my $s = '(??{$y})';
my $pat = qr/A (??{$x}) B $r C $s/x;
at perl compile time, the two '$x' code blocks are compiled, and their
optrees stored.
At runtime, when the $pat pattern is compiled, the third code block,
'$y', is compiled, and the two earlier optrees are retrieved. A new
three-element 'struct reg_code_blocks' array is malloc()ed, and the
pointers to the two old, and one new, optrees are stored in it.
Overall, $pat has the same effect as qr/A1B2C3/.
The assembly of this reg_code_blocks array is mostly performed by
S_concat_pat() and S_compile_runtime_code(). It is done incrementally,
since the total number of code blocks isn't known in advance.
Prior to this commit, the array was often realloced() and grown one
element at at a time, as each new run-time code block was discovered,
with a corresponding pRExC_state->code_blocks->count++.
This count field served twin purposes: it indicated both how many code
blocks had been found and stored so far, and the malloc()ed size of the
array. But some parts of the regex compiler allocate more than one slot
at a time, and so the two meanings of the 'count' field temporarily
diverge. This became noticeable when S_concat_pat() recursed to
interpolate the contents of an array, such as qr/$a$b@c/, where
interpolating $a, $b was done iteratively at the top level, then it
recursed to process each element of @c. S_concat_pat() had a local var,
'int n', which counted how many code blocks had been found so far, and
this value sometimes represented the difference between the two meanings
of the 'count' field.
However when it recursed, n started from zero again and things got out
of whack, which led to GH #16627. The bug in that ticket can be reduced
to:
my @x = ( qr/(?{A})/ );
qr/(?{B})@x/;
Here the B code block is stored in pRExC_state->code_blocks->cb[0],
but then S_concat_pat recurses, n is reset to 0, and the A code block is
also stored into slot 0. Then things would start to crash.
The quick and dirty fix would be to share n between recursive calls to
S_concat_pat(), by passing a pointer to it. Instead, this commit takes
the approach of adding a 'size' field to pRExC_state->code_blocks,
so that ->count now only indicates the current number of code blocks
stored (replacing the local var n) while ->size indicates the current
number of slots malloc()ed.
This makes the code more conventional and simpler to understand, and
allows the realloc() to pre-allocate rather than incrementing the array
size by 1 each time. By removing the fragile double meaning of the
'count' field, it should make any future bugs easier to diagnose, at the
cost of this initial commit being more complex.
Commit: 10656067f5a4a481ce355980ecde7425b4fe201f
https://github.com/Perl/perl5/commit/10656067f5a4a481ce355980ecde7425b4fe201f
Author: David Mitchell
Date: 2024-05-08 (Wed, 08 May 2024)
Changed paths:
M regcomp.c
M t/op/svleak.t
Log Message:
---
avoid leak in regex with overload and code block
When concatenating the components of a run-time pattern, if
a component has concat overloading, then that method is used, and
any previously accumulated code blocks - i.e. (?{...}) and similar -
are discarded. However, the ref counts of of any regex objects
pointed to which contained those code block(s) weren't having
their reference count decremented, and so leaked.
Spotted by code inspection while working on the previous commit.
Compare: https://github.com/Perl/perl5/compare/b74d82c33426%5E...10656067f5a4
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/p
[Perl/perl5]
Branch: refs/heads/davem/state_leak Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 17535c: fix refcount on cloned constant state subs
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 17535c984ae7d68304cc6e7b997240683f7fcadf
https://github.com/Perl/perl5/commit/17535c984ae7d68304cc6e7b997240683f7fcadf
Author: David Mitchell
Date: 2024-04-22 (Mon, 22 Apr 2024)
Changed paths:
M pad.c
M t/op/state.t
Log Message:
---
fix refcount on cloned constant state subs
Perl was doing this:
$ perl -e'sub { CORE::state sub FOO () { 42 } }'
Attempt to free unreferenced scalar: ...
$
This warning was in particular now showing up on stderr on bleed builds:
ever since the recent addition of similar code to Deparse.t with
v5.39.9-33-g4a55343c55.
When a sub is made constant, it is converted into an XS sub, and the
IV(42) SV is stored in the CV's CvXSUBANY(cv).any_sv field.
But state subs (even const ones) get cloned if wrapped within an outer
anon sub and then that outer sub gets cloned. And it turns out that when
a const state sub is cloned, the ref count of that const SV wasn't being
incremented.
The fix is trivial. But there were two possible ways to fix it. The
approach I chose was to fix the cloning code so that it increments on
CvCONST(cv) being true in addition to on CvREFCOUNTED_ANYSV(cv) being
true.
The other approach (and arguably more logically correct) would be to set
the CVf_REFCOUNTED_ANYSV flag on const subs too, but this involves
modifying the code in multiple places, e.g. newMYSUB(), newATTRSUB_x(),
newCONSTSUB_flags(), and makes it more likely that CPAN XS code out
there which cargo-cults similar code would also need fixing. So my fix
is simpler, more robust, but less satisfying.
Note that before 5.36.0, the failing code example above would segfault
rather than warn.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 3ed145: fix refcount on cloned constant state subs
Branch: refs/heads/davem/state_leak
Home: https://github.com/Perl/perl5
Commit: 3ed145ab00334466c0f1b3e7f342baf217083dd0
https://github.com/Perl/perl5/commit/3ed145ab00334466c0f1b3e7f342baf217083dd0
Author: David Mitchell
Date: 2024-04-19 (Fri, 19 Apr 2024)
Changed paths:
M pad.c
M t/op/state.t
Log Message:
---
fix refcount on cloned constant state subs
Perl was doing this:
$ perl -e'sub { CORE::state sub FOO () { 42 } }'
Attempt to free unreferenced scalar: ...
$
This warning was in particular now showing up on stderr on bleed builds:
ever since the recent addition of similar code to Deparse.t with
v5.39.9-33-g4a55343c55.
When a sub is made constant, it is converted into an XS sub, and the
IV(42) SV is stored in the CV's CvXSUBANY(cv).any_sv field.
But state subs (even const ones) get cloned if wrapped within an outer
anon sub and then that outer sub gets cloned. And it turns out that when
a const state sub is cloned, the ref count of that const SV wasn't being
incremented.
The fix is trivial. But there were two possible ways to fix it. The
approach I chose was to fix the cloning code so that it increments on
CvCONST(cv) being true in addition to on CvREFCOUNTED_ANYSV(cv) being
true.
The other approach (and arguably more logically correct) would be to set
the CVf_REFCOUNTED_ANYSV flag on const subs too, but this involves
modifying the code in multiple places, e.g. newMYSUB(), newATTRSUB_x(),
newCONSTSUB_flags(), and makes it more likely that CPAN XS code out
there which cargo-cults similar code would also need fixing. So my fix
is simpler, more robust, but less satisfying.
Note that before 5.36.0, the failing code example above would segfault
rather than warn.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] bcd28b: fixup comment in S_trie_bitmap_set_folded()
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: bcd28b1883bd29813e3d8a6c8e2330f87b91cbcc https://github.com/Perl/perl5/commit/bcd28b1883bd29813e3d8a6c8e2330f87b91cbcc Author: David Mitchell Date: 2024-04-02 (Tue, 02 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- fixup comment in S_trie_bitmap_set_folded() Karl pointed out that the comment was only accurate on non-EBCDIC systems. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] a73aa5: Minor fixups to S_trie_bitmap_set_folded()
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: a73aa540c8f8c4ec3268573ffcacdccbed9d0854 https://github.com/Perl/perl5/commit/a73aa540c8f8c4ec3268573ffcacdccbed9d0854 Author: David Mitchell Date: 2024-04-02 (Tue, 02 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- Minor fixups to S_trie_bitmap_set_folded() This is a new static function which replaces a similar macro. Yves pointed out that 'uvc' wasn't a good name for a variable which isn't of type UV, and Hugo pointed out that a (U8) cast was redundant. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/simplify_make_trie Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 336ff8: make TRIE_BITMAP_SET_FOLDED macro into a function
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 336ff86118129713ab83e0ed3654a3836d6f3078 https://github.com/Perl/perl5/commit/336ff86118129713ab83e0ed3654a3836d6f3078 Author: David Mitchell Date: 2024-04-02 (Tue, 02 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- make TRIE_BITMAP_SET_FOLDED macro into a function This is a private macro used just in regcomp_trie.c. It uses lots of macros itself, so locating problems quickly leads to Macro Hell. So this commit converts it into a static (but *not* inline) function. Commit: 589e2b8538d6d149efcec73b7d1dd78c59c4 https://github.com/Perl/perl5/commit/589e2b8538d6d149efcec73b7d1dd78c59c4 Author: David Mitchell Date: 2024-04-02 (Tue, 02 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- Slightly optimise S_trie_bitmap_set_folded() This static function in regcomp_trie.c evaluates UTF8_TWO_BYTE_HI(uvc) twice, because a macro it calls uses the passed expression twice. So calculate the value once into a local var. Now, the compiler might already optimise this. But this commit may or may not also have the (hoped for) side effect of shutting up a Coverity warning. The code is taking an 8-bit variant char, calculating what its upper byte would be if converted to utf-8 (so in this case, only 0xc2 and 0xc3 are possible), then setting a bit in a trie representing this value. The bit setting involves calculating the byte and bit offsets - the former by doing >>3. But doing that shift on c2/c3 always gives the same value, so Coverity is rightfully warning that UTF8_TWO_BYTE_HI(uvc) >> 3 is always constant. By splitting that expression into two statements, maybe Coverity won't notice. If it still does, at least this commit simplifies the code and will make any eventual fix easier. Here's the original Coverity report (it's complaining about the macro which the previous commit subsequently turned into a static function): >>> CID 488118:(CONSTANT_EXPRESSION_RESULT) >>> "(UV)(U8)(((UV)(*ch | 0) >> 6) | 192UL /* (U8)~(0xff >> 2) */) >> 3" is 0x18 regardless of the values of its operands. This occurs as a value. 1403 TRIE_BITMAP_SET_FOLDED(trie,*ch, folder); Compare: https://github.com/Perl/perl5/compare/0fff722e99f3...589e2b8538d6 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/coverity Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 0fff72: Perl_rcpv_new(): add assert(pv)
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 0fff722e99f30a5b4c8e2c5467539d90ec15fcab https://github.com/Perl/perl5/commit/0fff722e99f30a5b4c8e2c5467539d90ec15fcab Author: David Mitchell Date: 2024-04-02 (Tue, 02 Apr 2024) Changed paths: M op.c Log Message: --- Perl_rcpv_new(): add assert(pv) When this function is called with the RCPVf_USE_STRLEN flag, it gets the string length by calling strlen(pv). Coverity (CID 376192) points out that pv could be NULL. This commit adds an assert(pv), so that the code will bail out on the line before the strlen() in this case, which is probably enough to silence Coverity. Perhaps we aught to have a proper croak() there, but this is a utility function mainly used in limited places in the core, where the caller likely knows that they're doing. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] aaa937: Perl_rcpv_new(): add assert(pv)
Branch: refs/heads/davem/coverity Home: https://github.com/Perl/perl5 Commit: aaa937ab653d8f440944925d1b03d2a05955f9c3 https://github.com/Perl/perl5/commit/aaa937ab653d8f440944925d1b03d2a05955f9c3 Author: David Mitchell Date: 2024-04-01 (Mon, 01 Apr 2024) Changed paths: M op.c Log Message: --- Perl_rcpv_new(): add assert(pv) When this function is called with the RCPVf_USE_STRLEN flag, it gets the string length by calling strlen(pv). Coverity (CID 376192) points out that pv could be NULL. This commit adds an assert(pv), so that the code will bail out on the line before the strlen() in this case, which is probably enough to silence Coverity. Perhaps we aught to have a proper croak() there, but this is a utility function mainly used in limited places in the core, where the caller likely knows that they're doing. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] f7c9d5: make TRIE_BITMAP_SET_FOLDED macro into a function
Branch: refs/heads/davem/simplify_make_trie Home: https://github.com/Perl/perl5 Commit: f7c9d55bf7282c4d4cc155a4a3084ae328f19a96 https://github.com/Perl/perl5/commit/f7c9d55bf7282c4d4cc155a4a3084ae328f19a96 Author: David Mitchell Date: 2024-04-01 (Mon, 01 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- make TRIE_BITMAP_SET_FOLDED macro into a function This is a private macro used just in regcomp_trie.c. It uses lots of macros itself, so locating problems quickly leads to Macro Hell. So this commit converts it into a static (but *not* inline) function. Commit: d3ddc7c49dd025aab0bfcdc741dbfa6d0a71535e https://github.com/Perl/perl5/commit/d3ddc7c49dd025aab0bfcdc741dbfa6d0a71535e Author: David Mitchell Date: 2024-04-01 (Mon, 01 Apr 2024) Changed paths: M regcomp_trie.c Log Message: --- Slightly optimise S_trie_bitmap_set_folded() This static function in regcomp_trie.c evaluates UTF8_TWO_BYTE_HI(uvc) twice, because a macro it calls uses the passed expression twice. So calculate the value once into a local var. Now, the compiler might already optimise this. But this commit may or may not also have the (hoped for) side effect of shutting up a Coverity warning. The code is taking an 8-bit variant char, calculating what its upper byte would be if converted to utf-8 (so in this case, only 0xc2 and 0xc3 are possible), then setting a bit in a trie representing this value. The bit setting involves calculating the byte and bit offsets - the former by doing >>3. But doing that shift on c2/c3 always gives the same value, so Coverity is rightfully warning that UTF8_TWO_BYTE_HI(uvc) >> 3 is always constant. By splitting that expression into two statements, maybe Coverity won't notice. If it still does, at least this commit simplifies the code and will make any eventual fix easier. Here's the original Coverity report (it's complaining about the macro which the previous commit subsequently turned into a static function): >>> CID 488118:(CONSTANT_EXPRESSION_RESULT) >>> "(UV)(U8)(((UV)(*ch | 0) >> 6) | 192UL /* (U8)~(0xff >> 2) */) >> 3" is 0x18 regardless of the values of its operands. This occurs as a value. 1403 TRIE_BITMAP_SET_FOLDED(trie,*ch, folder); Compare: https://github.com/Perl/perl5/compare/f7c9d55bf728%5E...d3ddc7c49dd0 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] b74c4e: add CvEVAL_COMPILED() flag and fix closure bug.
Branch: refs/heads/davem/eval_compiled Home: https://github.com/Perl/perl5 Commit: b74c4e0b67e9cdfcefe3928d59e96aff10ad6f49 https://github.com/Perl/perl5/commit/b74c4e0b67e9cdfcefe3928d59e96aff10ad6f49 Author: David Mitchell Date: 2024-03-22 (Fri, 22 Mar 2024) Changed paths: M cv.h M dump.c M op.c M pad.c M t/op/eval.t Log Message: --- add CvEVAL_COMPILED() flag and fix closure bug. EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields don't get populated; instead the current values are stored in the PL_eval_root and PL_eval_start variables while they are being executed. This caused a bug in closures and nested evals when an inner eval was repeated twice. The first inner eval accessed an outer lexical, which caused a fake cache entry to be added to the outer eval's pad. The second inner eval finds this cached entry, but incorrectly concludes that the outer eval is in fact an anon sub prototype and issues a 'variable is not available' warning. This is due to this simplistic definition in pad.c: #define CvCOMPILED(cv) CvROOT(cv) This commit adds a new flag, CvEVAL_COMPILED(), to indicate a fully-compiled EVAL CV. This allows us to work around the limitation. In an ideal world this would have been fixed instead by making EVAL CVs first-class citizens with CvROOT() etc, but plenty of stuff seems to assume otherwise. So I took the path of least resistance. See https://www.perlmonks.org/?node_id=11158351 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 99efdb: add CvEVAL_COMPILED() flag and fix closure bug.
Branch: refs/heads/davem/eval_compiled Home: https://github.com/Perl/perl5 Commit: 99efdbdeaaf78a23ea899d194a250b7ff33ca069 https://github.com/Perl/perl5/commit/99efdbdeaaf78a23ea899d194a250b7ff33ca069 Author: David Mitchell Date: 2024-03-22 (Fri, 22 Mar 2024) Changed paths: M cv.h M dump.c M op.c M pad.c M t/op/eval.t Log Message: --- add CvEVAL_COMPILED() flag and fix closure bug. EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields don't get populated; instead the current values are stored in the PL_eval_root and PL_eval_start variables while they are being executed. This caused a bug in closures and nested evals when an inner eval was repeated twice. The first inner eval accessed an outer lexical, which caused a fake cache entry to be added to the outer eval's pad. The second inner eval finds this cached entry, but incorrectly concludes that the outer eval is in fact an anon sub prototype and issues a 'variable is not available' warning. This is due to this simplistic definition in pad.c: #define CvCOMPILED(cv) CvROOT(cv) This commit adds a new flag, CvEVAL_COMPILED(), to indicate a fully-compiled EVAL CV. This allows us to work around the limitation. In an ideal world this would have been fixed instead by making EVAL CVs first-class citizens with CvROOT() etc, but plenty of stuff seems to assume otherwise. So I took the path of least resistance. See https://www.perlmonks.org/?node_id=11158351 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/dump_flag Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] a74bf3: add CVf_XS_RCSTACK to dump output
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: a74bf3262c9b6b45c1cec5981d4c1dee9e493fd9 https://github.com/Perl/perl5/commit/a74bf3262c9b6b45c1cec5981d4c1dee9e493fd9 Author: David Mitchell Date: 2024-03-22 (Fri, 22 Mar 2024) Changed paths: M dump.c Log Message: --- add CVf_XS_RCSTACK to dump output This was missed when I added the flag To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 853535: add CVf_XS_RCSTACK to dump output
Branch: refs/heads/davem/dump_flag Home: https://github.com/Perl/perl5 Commit: 853535ccafe9e80d3b57b4c04b197c25c298a44c https://github.com/Perl/perl5/commit/853535ccafe9e80d3b57b4c04b197c25c298a44c Author: David Mitchell Date: 2024-03-21 (Thu, 21 Mar 2024) Changed paths: M dump.c Log Message: --- add CVf_XS_RCSTACK to dump output This was missed when I added the flag To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/newx_aux Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 4e836f: OP_METHSTART, OP_INITFIELD: use shared mem for aux
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 4e836fe9a8aee77f5e17a5db4b232508755038d6 https://github.com/Perl/perl5/commit/4e836fe9a8aee77f5e17a5db4b232508755038d6 Author: David Mitchell Date: 2024-03-19 (Tue, 19 Mar 2024) Changed paths: M class.c M op.c Log Message: --- OP_METHSTART, OP_INITFIELD: use shared mem for aux Allocate the aux structure for these two ops using PerlMemShared_malloc() rather then Newx(). OPs (and auxiliary structures) are shared between threads, and there's no guarantee that an OP will be freed by the same thread as the one which created it. Some OSes (Windows IIRC) get upset if memory is malloc()ed and free()d by different threads, since each thread has a separate malloc() pool. Hence we usually use PerlMemShared_malloc()/_free() to allocate such shared structs. These two recently-added ops were just using Newx(). This commit fixes them. No tests failures as far as I'm aware - this is more a theoretical thing where one thread compiles some code, creates a child, then exits. The child lives on, and when the child finally exits, the aux struct is freed to the wrong pool. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/tied_method_realav Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 047658: Perl_tied_method(): *conditionally* use RC stack
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 0476589cca34e34bc0ca3e11c01cffd9e7c60491 https://github.com/Perl/perl5/commit/0476589cca34e34bc0ca3e11c01cffd9e7c60491 Author: David Mitchell Date: 2024-03-18 (Mon, 18 Mar 2024) Changed paths: M pp_sys.c Log Message: --- Perl_tied_method(): *conditionally* use RC stack Fixes GH #21784. Perl_tied_method() is used to call tied methods for filehandles. One of its actions is to push a new stackinfo (and hence a new argument stack) to run the method under. When the method returns, any returned values are copied back to to original stack and the stackinfo popped. But stackinfos (and the AV pointed to by si_stack) aren't freed at that point; they are kept around until global destruction, in case they're needed again. Before this commit, Perl_tied_method() was incorrectly *always* making the new stack AvREAL: this should in fact be done only on PERL_RC_STACK builds. The effect of this was that, on non-PERL_RC_STACK builds, any temp SVs created as the return value(s) from the method call, would be left on the abandoned stack, while the SVs themselves have long since been freed. Normally this doesn't matter much - the array will be finally emptied only during global destruction, which doesn't care if an already-freed SV is attempted to be freed again. But this was causing Coro to fail, because it maintains a stackinfo chain per green thread, and manages and frees them itself, so they can end up being freed before global destruction, triggering an 'Attempt to free unreferenced scalar' warning. For completeness, this commit now also resets PL_stack_sp to PL_stack_base before abandoning the stack, so that that on PERL_RC_STACK builds, there's no chance of the copied return value SVs being double-counted later on, To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] c3ebd2: OP_METHSTART, OP_INITFIELD: use shared mem for aux
Branch: refs/heads/davem/newx_aux Home: https://github.com/Perl/perl5 Commit: c3ebd26582351105a25df19e205678ecc87c1708 https://github.com/Perl/perl5/commit/c3ebd26582351105a25df19e205678ecc87c1708 Author: David Mitchell Date: 2024-03-17 (Sun, 17 Mar 2024) Changed paths: M class.c M op.c Log Message: --- OP_METHSTART, OP_INITFIELD: use shared mem for aux Allocate the aux structure for these two ops using PerlMemShared_malloc() rather then Newx(). OPs (and auxiliary structures) are shared between threads, and there's no guarantee that an OP will be freed by the same thread as the one which created it. Some OSes (Windows IIRC) get upset if memory is malloc()ed and free()d by different threads, since each thread has a separate malloc() pool. Hence we usually use PerlMemShared_malloc()/_free() to allocate such shared structs. These two recently-added ops were just using Newx(). This commit fixes them. No tests failures as far as I'm aware - this is more a theoretical thing where one thread compiles some code, creates a child, then exits. The child lives on, and when the child finally exits, the aux struct is freed to the wrong pool. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 9d0763: Perl_tied_method(): *conditionally* use RC stack
Branch: refs/heads/davem/tied_method_realav Home: https://github.com/Perl/perl5 Commit: 9d0763202f9b83efe08b11749b3dc47ac27b0b6c https://github.com/Perl/perl5/commit/9d0763202f9b83efe08b11749b3dc47ac27b0b6c Author: David Mitchell Date: 2024-03-17 (Sun, 17 Mar 2024) Changed paths: M pp_sys.c Log Message: --- Perl_tied_method(): *conditionally* use RC stack Fixes GH #21784. Perl_tied_method() is used to call tied methods for filehandles. One of its actions is to push a new stackinfo (and hence a new argument stack) to run the method under. When the method returns, any returned values are copied back to to original stack and the stackinfo popped. But stackinfos (and the AV pointed to by si_stack) aren't freed at that point; they are kept around until global destruction, in case they're needed again. Before this commit, Perl_tied_method() was incorrectly *always* making the new stack AvREAL: this should in fact be done only on PERL_RC_STACK builds. The effect of this was that, on non-PERL_RC_STACK builds, any temp SVs created as the return value(s) from the method call, would be left on the abandoned stack, while the SVs themselves have long since been freed. Normally this doesn't matter much - the array will be finally emptied only during global destruction, which doesn't care if an already-freed SV is attempted to be freed again. But this was causing Coro to fail, because it maintains a stackinfo chain per green thread, and manages and frees them itself, so they can end up being freed before global destruction, triggering an 'Attempt to free unreferenced scalar' warning. For completeness, this commit now also resets PL_stack_sp to PL_stack_base before abandoning the stack, so that that on PERL_RC_STACK builds, there's no chance of the copied return value SVs being double-counted later on, To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 239af9: OP_METHSTART, OP_INITFIELD: use shared mem for aux
Branch: refs/heads/davem/newx_aux Home: https://github.com/Perl/perl5 Commit: 239af9f3786b2d5623067a25f061f2c2987b209f https://github.com/Perl/perl5/commit/239af9f3786b2d5623067a25f061f2c2987b209f Author: David Mitchell Date: 2024-03-17 (Sun, 17 Mar 2024) Changed paths: M class.c M op.c Log Message: --- OP_METHSTART, OP_INITFIELD: use shared mem for aux Allocate the aux structure for these two ops using PerlMemShared_malloc() rather then Newx(). OPs (and auxiliary structures) are shared between threads, and there's no guarantee that an OP will be freed by the same thread as the one which created it. Some OSes (Windows IIRC) get upset if memory is malloc()ed and free()d by different threads, since each thread has a separate malloc() pool. Hence we usually use PerlMemShared_malloc()/_free() to allocate such shared structs. These two recently-added ops were just using Newx(). This commit fixes them. No tests failures as far as I'm aware - this is more a theoretical thing where one thread compiles some code, creates a child, then exits. The child lives on, and when the child finally exits, the aux struct is freed to the wrong pool. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 150bc2: Perl_tied_method(): *conditionally* use RC stack
Branch: refs/heads/davem/tied_method_realav Home: https://github.com/Perl/perl5 Commit: 150bc24c60188bfb6b67da0c8a36fc75b1a70a25 https://github.com/Perl/perl5/commit/150bc24c60188bfb6b67da0c8a36fc75b1a70a25 Author: David Mitchell Date: 2024-03-17 (Sun, 17 Mar 2024) Changed paths: M pp_sys.c Log Message: --- Perl_tied_method(): *conditionally* use RC stack Fixes GH #21784. Perl_tied_method() is used to call tied methods for filehandles. One of its actions is to push a new stackinfo (and hence a new argument stack) to run the method under. When the method returns, any returned values are copied back to to original stack and the stackinfo popped. But stackinfos (and the AV pointed to by si_stack) aren't freed at that point; they are kept around until global destruction, in case they're needed again. Before this commit, Perl_tied_method() was incorrectly *always* making the new stack AvREAL: this should in fact be done only on PERL_RC_STACK builds. The effect of this was that, on non-PERL_RC_STACK builds, any temp SVs created as the return value(s) from the method call, would be left on the abandoned stack, while the SVs themselves have long since been freed. Normally this doesn't matter much - the array will be finally emptied only during global destruction, which doesn't care if an already-freed SV is attempted to be freed again. But this was causing Coro to fail, because it maintains a stackinfo chain per green thread, and manages and frees them itself, so they can end up being freed before global destruction, triggering an 'Attempt to free unreferenced scalar' warning. For completeness, this commit now also resets PL_stack_sp to PL_stack_base before abandoning the stack, so that that on PERL_RC_STACK builds, there's no chance of the copied return value SVs being double-counted later on, To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] b65f3b: Perl_tied_method(): *conditionally* use RC stack
Branch: refs/heads/davem/tied_method_realav Home: https://github.com/Perl/perl5 Commit: b65f3b65c9326207e36c55ebc6a140f3230b32f4 https://github.com/Perl/perl5/commit/b65f3b65c9326207e36c55ebc6a140f3230b32f4 Author: David Mitchell Date: 2024-03-17 (Sun, 17 Mar 2024) Changed paths: M pp_sys.c Log Message: --- Perl_tied_method(): *conditionally* use RC stack Fixes GH #21784. Perl_tied_method() is used to call tied methods for filehandles. One of its actions is to push a new stackinfo (and hence a new argument stack) to run the method under. When the method returns, any returned values are copied back to to original stack and the stackinfo popped. But stackinfos (and the AV pointed to by si_stack) aren't freed at that point; they are kept around until global destruction, in case they're needed again. Before this commit, Perl_tied_method() was incorrectly *always* making the new stack AvREAL: this should in fact be done only on PERL_RC_STACK builds. The effect of this was that, on non-PERL_RC_STACK builds, any temp SVs created as the return value(s) from the method call, would be left on the abandoned stack, while the SVs themselves have long since been freed. Normally this doesn't matter much - the array will be finally emptied only during global destruction, which doesn't care if an already-freed SV is attempted to be freed again. But this was causing Coro to fail, because it maintains a stackinfo chain per green thread, and manages and frees them itself, so they can end up being freed before global destruction, triggering an 'Attempt to free unreferenced scalar' warning. For completeness, this commit now also resets PL_stack_sp to PL_stack_base before abandoning the stack, so that that on PERL_RC_STACK builds, there's no chance of the copied return value SVs being double-counted later on, To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/padsv_store_unvoid Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] dc524b: Revert "OP_PADSV_STORE: only in void context"
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: dc524b6cbd75e78c018e9ad6dd1b2d9c5eee6a20 https://github.com/Perl/perl5/commit/dc524b6cbd75e78c018e9ad6dd1b2d9c5eee6a20 Author: David Mitchell Date: 2024-02-28 (Wed, 28 Feb 2024) Changed paths: M ext/B/t/optree_varinit.t M peep.c M pp_hot.c M t/perf/opcount.t Log Message: --- Revert "OP_PADSV_STORE: only in void context" This is merely an optimisation, which is breaking some CPAN modules due to expectations about particular optree structures. Revert for now and worry about it again after 5.40 is released. See https://github.com/Perl/perl5/issues/21822 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 27f904: Revert "OP_PADSV_STORE: only in void context"
Branch: refs/heads/davem/padsv_store_unvoid Home: https://github.com/Perl/perl5 Commit: 27f904b378493de59d3561891bdfdefec5caeecb https://github.com/Perl/perl5/commit/27f904b378493de59d3561891bdfdefec5caeecb Author: David Mitchell Date: 2024-02-27 (Tue, 27 Feb 2024) Changed paths: M ext/B/t/optree_varinit.t M peep.c M pp_hot.c M t/perf/opcount.t Log Message: --- Revert "OP_PADSV_STORE: only in void context" This is merely an optimisation, which is breaking some CPAN modules due to expectations about particular optree structures. Revert for now and worry about it again after 5.40 is released. See https://github.com/Perl/perl5/issues/21822 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/tie-file-tmpdir Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 0dcb31: Tie::File: use File::Temp in two test scripts
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 0dcb31c5c86b04e1b52bb0eb548d3430ae796dd5 https://github.com/Perl/perl5/commit/0dcb31c5c86b04e1b52bb0eb548d3430ae796dd5 Author: David Mitchell Date: 2024-02-27 (Tue, 27 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t M dist/Tie-File/t/29a_upcopy.t Log Message: --- Tie::File: use File::Temp in two test scripts t/29_downcopy.t and t/29a_upcopy.t intermittently timeout on some smokers. This is speculated to be due to the current directory being on a very slow USB drive, when lots of small test files are created, modified and deleted by these tests. So making these tests I/O bound rather than CPU bound. Update these two test scripts to use File::Temp to create a temp subdir in the OS's normal temp directory as a place for the temp files, rather than just the current directory. This has two potential advantages. First the OS's normal tempdir (e.g. /tmp or wherever $TMPDIR points to) may be mounted as tmpfs or similar, and thus won't actually write to a slow USB or network drive. Second, each test file will be created in directory that's normally empty, so there's potentially less manipulating of the directory information on disk. In this thread, http://nntp.perl.org/group/perl.perl5.porters/267991 the wallclock time taken for 29_downcopy.t on a raspberry pi reduced from 55.29s to 0.91s with the application of this patch. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 529b0e: t/harness: remove Encode parallel test exception
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 529b0eee5b68112baa6223f86e8db382fd7443c4 https://github.com/Perl/perl5/commit/529b0eee5b68112baa6223f86e8db382fd7443c4 Author: David Mitchell Date: 2024-02-26 (Mon, 26 Feb 2024) Changed paths: M t/harness Log Message: --- t/harness: remove Encode parallel test exception The new version of Encode, which was just merged, includes a fix that stops two test scripts from using the same temp files. So remove the exception which stops those two test scripts running in parallel. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 529b0e: t/harness: remove Encode parallel test exception
Branch: refs/heads/davem/tie-file-tmpdir Home: https://github.com/Perl/perl5 Commit: 529b0eee5b68112baa6223f86e8db382fd7443c4 https://github.com/Perl/perl5/commit/529b0eee5b68112baa6223f86e8db382fd7443c4 Author: David Mitchell Date: 2024-02-26 (Mon, 26 Feb 2024) Changed paths: M t/harness Log Message: --- t/harness: remove Encode parallel test exception The new version of Encode, which was just merged, includes a fix that stops two test scripts from using the same temp files. So remove the exception which stops those two test scripts running in parallel. Commit: ada486377b7b9f6baba2f0061ff2b16308c577d3 https://github.com/Perl/perl5/commit/ada486377b7b9f6baba2f0061ff2b16308c577d3 Author: David Mitchell Date: 2024-02-26 (Mon, 26 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t M dist/Tie-File/t/29a_upcopy.t Log Message: --- Tie::File: use File::Temp in two test scripts t/29_downcopy.t and t/29a_upcopy.t intermittently timeout on some smokers. This is speculated to be due to the current directory being on a very slow USB drive, when lots of small test files are created, modified and deleted by these tests. Update these two test scripts to use File::Temp to create a temp subdir in the OS's normal temp directory as a place for the temp files. This has two potential advantages. First the OS's normal tempdir (e.g. /tmp or wherever $TMPDIR points to) may be mounted as tmpfs or similar, and thus won't actually write to a slow USB or network drive. Second, each test file will be created in directory that's normally empty, so there's potentially less manipulating of the directory information on disk. Compare: https://github.com/Perl/perl5/compare/529b0eee5b68%5E...ada486377b7b To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/smoke-fixes Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] de05a3: Fix parallel smoke failure in Encode.
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: de05a3dc13c9866907d46aa499187be02e79d607 https://github.com/Perl/perl5/commit/de05a3dc13c9866907d46aa499187be02e79d607 Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M t/harness Log Message: --- Fix parallel smoke failure in Encode. These two tests shouldn't be run in parallel: cpan/Encode/t/CJKT.t cpan/Encode/t/Unicode.t Commit: de42fb9fd3c557a8064eadd20256cc97805bae6f https://github.com/Perl/perl5/commit/de42fb9fd3c557a8064eadd20256cc97805bae6f Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t M dist/Tie-File/t/29a_upcopy.t Log Message: --- Tie-File: make some test files give better output For 29_downcopy.t and 29a_upcopy.t, which both just call a function try() many times with different args, make the 'ok NNN' line and any diagnotics display the parameters and the line number of the caller. Commit: 6c203a272128bb43e2b788ae06e534046f0d31e4 https://github.com/Perl/perl5/commit/6c203a272128bb43e2b788ae06e534046f0d31e4 Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t Log Message: --- Tie-File: slightly simplify t/29_downcopy.t The try() function tail-calls itself with $len set to undef, so each call to try() carries out *two* sets of (almost identical) tests. Make the code simpler by removing the recursion and instead make try() a small wrapper function which calls the main test function (now renamed try0) twice, the second time with $len set to undef. This makes it easier to see what's going on. This should make no changes to what gets tested. Commit: 71114dea2386a44414f0db835bd01fac2697df4f https://github.com/Perl/perl5/commit/71114dea2386a44414f0db835bd01fac2697df4f Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t Log Message: --- Tie-File: 29_downcopy.t: improve 'ok' output Each call to try does two ok's: make the description vary slightly between the two ok outputs to distinguish them. Commit: dc16024220239adbacd408285d27aa31c89b90e6 https://github.com/Perl/perl5/commit/dc16024220239adbacd408285d27aa31c89b90e6 Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t M dist/Tie-File/t/29a_upcopy.t M t/harness Log Message: --- [MERGE] assorted smoke fixes Stop some tests running in parallel which aren't safe to so so, and improve the diagnostics on some Tie::File tests which randomly timeout on slow hosts. Compare: https://github.com/Perl/perl5/compare/ad4a6d926044...dc1602422023 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] de05a3: Fix parallel smoke failure in Encode.
Branch: refs/heads/davem/smoke-fixes Home: https://github.com/Perl/perl5 Commit: de05a3dc13c9866907d46aa499187be02e79d607 https://github.com/Perl/perl5/commit/de05a3dc13c9866907d46aa499187be02e79d607 Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M t/harness Log Message: --- Fix parallel smoke failure in Encode. These two tests shouldn't be run in parallel: cpan/Encode/t/CJKT.t cpan/Encode/t/Unicode.t Commit: de42fb9fd3c557a8064eadd20256cc97805bae6f https://github.com/Perl/perl5/commit/de42fb9fd3c557a8064eadd20256cc97805bae6f Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t M dist/Tie-File/t/29a_upcopy.t Log Message: --- Tie-File: make some test files give better output For 29_downcopy.t and 29a_upcopy.t, which both just call a function try() many times with different args, make the 'ok NNN' line and any diagnotics display the parameters and the line number of the caller. Commit: 6c203a272128bb43e2b788ae06e534046f0d31e4 https://github.com/Perl/perl5/commit/6c203a272128bb43e2b788ae06e534046f0d31e4 Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t Log Message: --- Tie-File: slightly simplify t/29_downcopy.t The try() function tail-calls itself with $len set to undef, so each call to try() carries out *two* sets of (almost identical) tests. Make the code simpler by removing the recursion and instead make try() a small wrapper function which calls the main test function (now renamed try0) twice, the second time with $len set to undef. This makes it easier to see what's going on. This should make no changes to what gets tested. Commit: 71114dea2386a44414f0db835bd01fac2697df4f https://github.com/Perl/perl5/commit/71114dea2386a44414f0db835bd01fac2697df4f Author: David Mitchell Date: 2024-02-25 (Sun, 25 Feb 2024) Changed paths: M dist/Tie-File/t/29_downcopy.t Log Message: --- Tie-File: 29_downcopy.t: improve 'ok' output Each call to try does two ok's: make the description vary slightly between the two ok outputs to distinguish them. Compare: https://github.com/Perl/perl5/compare/de05a3dc13c9%5E...71114dea2386 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] ef72a9: Don't run File::Find tests in parallel
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: ef72a9add3d4aa7e662b9777192c07ef1b88fe15 https://github.com/Perl/perl5/commit/ef72a9add3d4aa7e662b9777192c07ef1b88fe15 Author: David Mitchell Date: 2024-02-23 (Fri, 23 Feb 2024) Changed paths: M t/harness Log Message: --- Don't run File::Find tests in parallel We were seeing intermittent smoke failures for find.t and taint.t, with errors in the logs like Can't cd to .. from ./FF_find_t_RKdkBE/for_find/fb: Stale file handle where the temp dir it was complaining about is one actually created by the *other* test file. So it seems that it's best not to run these two tests in parallel. I suppose a more complete solution would be to have two separate permanent test dirs with two sets of test files for the two test scripts to play with, but that sounds like a lot of work. In the meantime, lets see if the problem goes away with this quick fix. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/line Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 2bb889: add OPpCONST_TOKEN_* flags to aid deparsing
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 2bb889fc6c12b192e0fcde37af5e638d5cb8e181 https://github.com/Perl/perl5/commit/2bb889fc6c12b192e0fcde37af5e638d5cb8e181 Author: David Mitchell Date: 2024-02-22 (Thu, 22 Feb 2024) Changed paths: M Porting/deparse-skips.txt M lib/B/Deparse.pm M lib/B/Deparse.t M lib/B/Op_private.pm M opcode.h M regen/op_private M toke.c Log Message: --- add OPpCONST_TOKEN_* flags to aid deparsing Code like my $line = __LINE__; my $file = __FILE__; my $pkg = __PACKAGE__; was being deparsed as my $line = '42'; my $file = 'foo.pl'; my $pkg = 'Foo::Bar'; because __LINE__ etc are converted by the lexer into an ordinary OP_CONST, whose SV is just a plain string holding the line number or whatever. This commit uses two spare bits in op_private on OP_CONST ops to create a 4-valued bit field, indicating whether the op is a normal constant or one of those three special constant tokens. This field is then used by Deparse to output a literal "__LINE__" or whatever rather than the value of the constant. This fixes one failing test file under cd t; ./TEST -deparse and removes one (but not all) sources of failure from three others. Note that __SUB__ is already special-cased to deparse literally (except when used outside a sub where it deparses as 'undef'), while the special tokens __DATA__, __END__ and __CLASS__ don't generate OP_CONSTs. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 193e81: add OPpCONST_TOKEN_* flags to aid deparsing
Branch: refs/heads/davem/line Home: https://github.com/Perl/perl5 Commit: 193e8180e5b95830b28369f5dfd1fdfffddaae79 https://github.com/Perl/perl5/commit/193e8180e5b95830b28369f5dfd1fdfffddaae79 Author: David Mitchell Date: 2024-02-22 (Thu, 22 Feb 2024) Changed paths: M Porting/deparse-skips.txt M lib/B/Deparse.pm M lib/B/Deparse.t M lib/B/Op_private.pm M opcode.h M regen/op_private M toke.c Log Message: --- add OPpCONST_TOKEN_* flags to aid deparsing Code like my $line = __LINE__; my $file = __FILE__; my $pkg = __PACKAGE__; was being deparsed as my $line = '42'; my $file = 'foo.pl'; my $pkg = 'Foo::Bar'; because __LINE__ etc are converted by the lexer into an ordinary OP_CONST, whose SV is just a plain string holding the line number or whatever. This commit uses two spare bits in op_private on OP_CONST ops to create a 4-valued bit field, indicating whether the op is a normal constant or one of those three special constant tokens. This field is then used by Deparse to output a literal "__LINE__" or whatever rather than the value of the constant. This fixes one failing test file under cd t; ./TEST -deparse and removes one (but not all) sources of failure from three others. Note that __SUB__ is already special-cased to deparse literally (except when used outside a sub where it deparses as 'undef'), while the special tokens __DATA__, __END__ and __CLASS__ don't generate OP_CONSTs. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] b8dc1b: add OPpCONST_TOKEN_* flags to aid deparsing
Branch: refs/heads/davem/line Home: https://github.com/Perl/perl5 Commit: b8dc1bde27552525caf5b5ad0ee964cdfc48b7e5 https://github.com/Perl/perl5/commit/b8dc1bde27552525caf5b5ad0ee964cdfc48b7e5 Author: David Mitchell Date: 2024-02-21 (Wed, 21 Feb 2024) Changed paths: M Porting/deparse-skips.txt M lib/B/Deparse.pm M lib/B/Deparse.t M lib/B/Op_private.pm M opcode.h M regen/op_private M toke.c Log Message: --- add OPpCONST_TOKEN_* flags to aid deparsing Code like my $line = __LINE__; my $file = __FILE__; my $pkg = __PACKAGE__; was being deparsed as my $line = '42'; my $file = 'foo.pl'; my $pkg = 'Foo::Bar'; because __LINE__ etc are converted by the lexer into an ordinary OP_CONST, whose SV is just a plain string holding the line number or whatever. This commit uses two spare bits in op_private on OP_CONST ops to create a 4-valued bit field, indicating whether the op is a normal constant or one of those three special constant tokens. This field is then used by Deparse to output a literal "__LINE__" or whatever rather than the value of the constant. This fixes one failing test file under cd t; ./TEST -deparse and removes one (but not all) sources of failure from three others. Note that __SUB__ is already special-cased to deparse literally (except when used outside a sub where it deparses as 'undef'), while the special tokens __DATA__, __END__ and __CLASS__ don't generate OP_CONSTs. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5]
Branch: refs/heads/davem/mini Home: https://github.com/Perl/perl5 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 0769ab: make t/op/refstack.t work under minitest
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 0769ab21fc98e79ad1208c6ea555b4bd3b441772 https://github.com/Perl/perl5/commit/0769ab21fc98e79ad1208c6ea555b4bd3b441772 Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M t/op/refstack.t Log Message: --- make t/op/refstack.t work under minitest Skip a test that won't run under miniperl. Commit: da5599dc376d465eb3f376886b58de7510c8e0f7 https://github.com/Perl/perl5/commit/da5599dc376d465eb3f376886b58de7510c8e0f7 Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M t/op/lex.t Log Message: --- make t/op/lex.t work under minitest One of the tests fails if there happens to a file called "t/0" left lying around. For some reason, such a file appears to get created and then *not* deleted under 'make minitest'. So delete it just it case. Commit: ff8b298b446c457c7aa33fcd54b88c094979e218 https://github.com/Perl/perl5/commit/ff8b298b446c457c7aa33fcd54b88c094979e218 Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M pp_hot.c M pp_sys.c Log Message: --- pp_glob() and miniperl - remove an assertion My recent-ish commit v5.39.5-86-g651f4b6c76 updated pp_glob and similar code to handle a ref-counted stack. I partially misunderstood how globbing works under PERL_EXTERNAL_GLOB, which is normally defined only when building miniperl. This commit updates some of the code comments added by that commit (including a couple of typos), and importantly, removes an assertion which that commit added, that turns out to have been wrong. The assertion removal makes these two test files pass again under minitest: t/op/defins.t t/op/glob.t Commit: bd5dc005d91aed1768beb71f8a105f31aa8a8f0b https://github.com/Perl/perl5/commit/bd5dc005d91aed1768beb71f8a105f31aa8a8f0b Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M Porting/deparse-skips.txt Log Message: --- deparse-skips.txt: add some more skips. The new class stuff doesn't generally Deparse yet. lib/builtin.t fails to handle PADNAMEf_TOMBSTONE, which is likely to be removed soon, anyway. Commit: 88b4048ad6c9a1758fcc6d185560aa9e34300851 https://github.com/Perl/perl5/commit/88b4048ad6c9a1758fcc6d185560aa9e34300851 Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M Porting/deparse-skips.txt M pp_hot.c M pp_sys.c M t/op/lex.t M t/op/refstack.t Log Message: --- [MERGE] get minitest and Test -deparse to pass Some stuff was failing, especially under PERL_RC_STACK. Compare: https://github.com/Perl/perl5/compare/1b8912b317b2...88b4048ad6c9 To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 74a044: add OPpCONST_LINE flag to aid deparsing
Branch: refs/heads/davem/line Home: https://github.com/Perl/perl5 Commit: 74a04465d47440e72b5b577d331a741a2c313461 https://github.com/Perl/perl5/commit/74a04465d47440e72b5b577d331a741a2c313461 Author: David Mitchell Date: 2024-02-19 (Mon, 19 Feb 2024) Changed paths: M Porting/deparse-skips.txt M lib/B/Deparse.pm M lib/B/Deparse.t M lib/B/Op_private.pm M opcode.h M regen/op_private M toke.c Log Message: --- add OPpCONST_LINE flag to aid deparsing Code like my $line = __LINE__; was being deparsed as my $line = '42'; because __LINE__ is converted by the lexer into an ordinary OP_CONST whose SV is just a plain string holding the line number. This commit adds a flag, OPpCONST_LINE, to OP_CONST, which is set to indicate that this OP_CONST was created from a __LINE__ construct. Deparse.pm then uses this new flag to print out the literal string "__LINE__" rather than the constant's actual value. This fixes one failing test file under cd t; ./TEST -deparse and removes one (but not all) sources of failure from three others. To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 82d58d: make t/op/refstack.t work under minitest
Branch: refs/heads/davem/mini Home: https://github.com/Perl/perl5 Commit: 82d58d082dbbc57540f6f0a42484c37cdf066b67 https://github.com/Perl/perl5/commit/82d58d082dbbc57540f6f0a42484c37cdf066b67 Author: David Mitchell Date: 2024-02-18 (Sun, 18 Feb 2024) Changed paths: M t/op/refstack.t Log Message: --- make t/op/refstack.t work under minitest Skip a test that won't run under miniperl. Commit: a8c3bacef7ae40b8e9834a8263a9b089cade0e41 https://github.com/Perl/perl5/commit/a8c3bacef7ae40b8e9834a8263a9b089cade0e41 Author: David Mitchell Date: 2024-02-18 (Sun, 18 Feb 2024) Changed paths: M t/op/lex.t Log Message: --- make t/op/lex.t work under minitest One of the tests fails if there happens to a file called "t/0" left lying around. For some reason, such a file appears to get created and then *not* deleted under 'make minitest'. So delete it just it case. Commit: cb7bbd38b7f3844c85b64c701c4bb20b9db586d6 https://github.com/Perl/perl5/commit/cb7bbd38b7f3844c85b64c701c4bb20b9db586d6 Author: David Mitchell Date: 2024-02-18 (Sun, 18 Feb 2024) Changed paths: M pp_hot.c M pp_sys.c Log Message: --- pp_glob() and miniperl - remove an assertion My recent-ish commit v5.39.5-86-g651f4b6c76 updated pp_glob and similar code to handle a ref-counted stack. I partially misunderstood how globbing works under PERL_EXTERNAL_GLOB, which is normally defined only when building miniperl. This commit updates some of the code comments added by that commit (including a couple of typos), and importantly, removes an assertion which that commit added, that turns out to have been wrong. The assertion removal makes these two test files pass again under minitest: t/op/defins.t t/op/glob.t Commit: a00e92a032dfc6d1cb5fe667f52e7505eb5e6eff https://github.com/Perl/perl5/commit/a00e92a032dfc6d1cb5fe667f52e7505eb5e6eff Author: David Mitchell Date: 2024-02-18 (Sun, 18 Feb 2024) Changed paths: M Porting/deparse-skips.txt Log Message: --- deparse-skips.txt: add some more skips. The new class stuff doesn't generally Deparse yet. lib/builtin.t fails to handle PADNAMEf_TOMBSTONE, which is likely to be removed soon, anyway. Compare: https://github.com/Perl/perl5/compare/82d58d082dbb%5E...a00e92a032df To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] 2e906f: deparse-skips.txt: remove deleted files
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 2e906f46333a87edae760d067a81a38cdc379f34 https://github.com/Perl/perl5/commit/2e906f46333a87edae760d067a81a38cdc379f34 Author: David Mitchell Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M Porting/deparse-skips.txt Log Message: --- deparse-skips.txt: remove deleted files Remove two files listed for skipping that have since been removed from the perl distribution. Commit: a8c98abf827edfaf8de7e6654afb4cb6717831e6 https://github.com/Perl/perl5/commit/a8c98abf827edfaf8de7e6654afb4cb6717831e6 Author: David Mitchell Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M Porting/deparse-skips.txt Log Message: --- deparse-skips.txt: add new skips Skip the new file cpan/autodie/t/exceptions-smartmatch.t: all autodie test files get skipped due to failure to deparse user-hints. Skip the three new Test2-Suit test files, because they use __LINE__, which gets deparsed as a number rather than __LINE__. Compare: https://github.com/Perl/perl5/compare/16b59695a65e...a8c98abf827e To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications
[Perl/perl5] fec143: t/op/sub.t: silence new warning
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: fec143064bf91a9f3cc6a3b3c77b33e1654c0bd0 https://github.com/Perl/perl5/commit/fec143064bf91a9f3cc6a3b3c77b33e1654c0bd0 Author: David Mitchell Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M t/op/sub.t Log Message: --- t/op/sub.t: silence new warning A 7-year old test has recently started emitting this warning: Lexical subroutine &b masks previously declared package subroutine because a new warning has been added to core. It's not 100% clear to me whether the test itself was *relying* on a package subroutine having the same name or not, but given that it was a test which crashed rather than had well-defined "bad" behaviour", I decided it was best to leave the test exactly as-is, and just silence the warning.
[Perl/perl5]
Branch: refs/heads/davem/clone Home: https://github.com/Perl/perl5
[Perl/perl5] 75bedf: avoid ext/XS-APItest/t/clone-with-stack.t crash
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 75bedfb8dffceedb73beb63be21076e0956886b2
https://github.com/Perl/perl5/commit/75bedfb8dffceedb73beb63be21076e0956886b2
Author: David Mitchell
Date: 2024-02-16 (Fri, 16 Feb 2024)
Changed paths:
M ext/XS-APItest/APItest.xs
Log Message:
---
avoid ext/XS-APItest/t/clone-with-stack.t crash
a fresh_perl() TODO test in this file does something like
use XS::APItest;
BEGIN {
clone_with_stack();
}
print "ok\n";
As a standalone program, this code gives errors under valgrind,
and in ticket GH #21969 was causing "perl.exe has stopped working" on
Windows 8.
The clone_with_stack() XS function is fairly dodgy - it clones the whole
interpreter including stacks (i.e. what fork() emulation on windows
does), but then continues the RUNOPS loop to completion itself, using
the cloned interpreter, rather than relying on the caller to finish the
ops loop.
This doesn't work very well under BEGIN (hence why it's a TODO test),
but specifically, PL_curcop can be left pointing at an op which gets
freed , but then is later accessed anyway.
This commit resets PL_curcop to &PL_compiling to avoid crashes.
[Perl/perl5] cd546b: avoid ext/XS-APItest/t/clone-with-stack.t crash
Branch: refs/heads/davem/clone
Home: https://github.com/Perl/perl5
Commit: cd546bd54a2be65514cec6198352fafda0cb0787
https://github.com/Perl/perl5/commit/cd546bd54a2be65514cec6198352fafda0cb0787
Author: David Mitchell
Date: 2024-02-12 (Mon, 12 Feb 2024)
Changed paths:
M ext/XS-APItest/APItest.xs
Log Message:
---
avoid ext/XS-APItest/t/clone-with-stack.t crash
a fresh_perl() TODO test in this file does something like
use XS::APItest;
BEGIN {
clone_with_stack();
}
print "ok\n";
As a standalone program, this code gives errors under valgrind,
and in ticket GH #21969 was causing "perl.exe has stopped working" on
Windows 8.
The clone_with_stack() XS function is fairly dodgy - it clones the whole
interpreter including stacks (i.e. what fork() emulation on windows
does), but then continues the RUNOPS loop to completion itself, using
the cloned interpreter, rather than relying on the caller to finish the
ops loop.
This doesn't work very well under BEGIN (hence why it's a TODO test),
but specifically, PL_curcop can be left pointing at an op which gets
freed , but then is later accessed anyway.
This commit resets PL_curcop to &PL_compiling to avoid crashes.
[Perl/perl5] ed7993: Perl_amagic_call(): don't assume non-NULL PL_op
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: ed79937e388a8232abe29c064ca4863b6b2cc1be https://github.com/Perl/perl5/commit/ed79937e388a8232abe29c064ca4863b6b2cc1be Author: David Mitchell Date: 2024-01-16 (Tue, 16 Jan 2024) Changed paths: M gv.c Log Message: --- Perl_amagic_call(): don't assume non-NULL PL_op This line in Perl_amagic_call(): U8 gimme = (force_scalar || PL_op->op_type == OP_MULTICONCAT) relies on either PL_op always being non-null, or for the times that PL_op is null, that force_scalar always ends up being true. As it happens, qr// with constant overloading calls Perl_amagic_call() with a null PL_op, but also with method=string_amg, which happens to set force_scalar. Add a check for PL_op being non-null, partly to future-proof the code, but mainly to shut up Coverity, which rightly pointed out that some new code added by me with v5.39.6-107-g547324acdb *does* check for PL_op being non-null earlier in the function, and if there's one thing Coverity can't abide, it's inconsistency.
[Perl/perl5]
Branch: refs/heads/davem/rc7 Home: https://github.com/Perl/perl5
[Perl/perl5] c94929: add Concise tests for state var assignment
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: c949292055f73373ddef8037677075cfe1a78fc2
https://github.com/Perl/perl5/commit/c949292055f73373ddef8037677075cfe1a78fc2
Author: David Mitchell
Date: 2024-01-09 (Tue, 09 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
Log Message:
---
add Concise tests for state var assignment
Add tests for
state $x = 1;
my $y = state $x = 1;
to check what context is allocated to the various ops. At the moment it
is actually wrong in places, and this commit captures that wrongness.
The next commit will fix this, and those diffs to the tests added in this
commit will help make it clear what has changed.
Commit: dbcd7f4a222753b4329ac1def41fc1048fbc438b
https://github.com/Perl/perl5/commit/dbcd7f4a222753b4329ac1def41fc1048fbc438b
Author: David Mitchell
Date: 2024-01-09 (Tue, 09 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M op.c
Log Message:
---
set context in 'state' expressions
The ops associated with a state variable declaration and initial
assignment weren't getting their context (GIMME) assigned.
Background:
state $x = ...;
gets compiled to something similar to
if (first_time)
$x = ...;
else
$x;
Except that the 'if' is performed by an OP_ONCE logop, which checks and
updates a flag in the pad, and branches to op_next or op_other as
appropriate.
During compilation, the context of the state expression wasn't being
passed on to the children of the OP_ONCE. So the assignment (optimised
into a padsv_store) and the padsv were left as UNKNOWN rather than VOID
or SCALAR as appropriate, as in these two examples:
state $x = 1; # should be void
$y = (state $x = 1); # should be scalar
This commit fixes that. Note that at the moment it makes no practical
difference, since the padsv/padsv_store ops don't currently change
their behaviour based on context, but that might change.
Commit: 547324acdb2344f04378d3c32330b611dc0bd519
https://github.com/Perl/perl5/commit/547324acdb2344f04378d3c32330b611dc0bd519
Author: David Mitchell
Date: 2024-01-09 (Tue, 09 Jan 2024)
Changed paths:
M gv.c
M op.c
M pp.c
Log Message:
---
Give OPpTARGET_MY ops real context
Perl has an optimisation whereby an op which returns the RHS of a scalar
assignment to a lexical, and which would normally store its result in
a PADTMP, instead skips the following PADSV and SASSIGN ops and assigns
to the lexical directly, instead of to the PADTMP. For example in
$lex = $a + $b;
the ops (in execution-order) would be changed from
add[t5] sK/2
gvsv[*lex] s
sassign vKS/2
nextstate(main 2 -e:1) v:{
to
add[$lex:1,2] sK/TARGMY,2
nextstate(main 2 -e:1) v:{
However, note that although that the add op is now essentially called in
void context, it is still marked as being in scalar context. This commit
changes it to be be marked as void, i.e.
add[$lex:1,2] vK/TARGMY,2
The main reason for this is to allow for future optimisations in
functions like pp_add(), which will be able to skip pushing the result
onto the stack in in void context. It just so happens that scalar
assignments to lexical vars are typically in void context.
However, since this is a visible change from the perspective of modules
which examine ops or optrees, I'll leave doing any optimisations until
later, in case this commit needs to be reverted.
The main things this commit had to fix up following the change were:
- still call overload methods in scalar context, even though the op is
now marked as void;
- not issuing "useless use of add in void context" style warnings on
such ops;
- making pp_push and pp_unshift still set TARG in void context
No matter whether the op's context is marked as scalar or as void, some
parts of perl will misunderstand, and will need to be special-cased
(since the op is really both, depending on your perspective). So this
commit changes the burden of the special-casing code to be in the
non-hot code paths, like during complication or when calling out to an
overload method.
Commit: c90e7ed39e5df8d5915422454fb76198801f3563
https://github.com/Perl/perl5/commit/c90e7ed39e5df8d5915422454fb76198801f3563
Author: David Mitchell
Date: 2024-01-09 (Tue, 09 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M peep.c
M pp_hot.c
M t/perf/opcount.t
Log Message:
---
OP_PADSV_STORE: only in void context
For the optimisation which converts $lex = expr into an OP_PADSV_STORE
op, only optimise if the scalar assign is in VOID context.
This allows us to stop pp_padsv_store() from uselessly pushing the
result onto the stack, only to be immediately popped again by the
following nextstate or unstack op. This becomes more important on
PERL_RC_STACK builds, as each push or pop involves manipulating the SV's
reference count.
I'm working on the a
[Perl/perl5] 228066: add Concise tests for state var assignment
Branch: refs/heads/davem/rc7
Home: https://github.com/Perl/perl5
Commit: 2280665a0c90f669febc20e2dec4ad96f11c9c7e
https://github.com/Perl/perl5/commit/2280665a0c90f669febc20e2dec4ad96f11c9c7e
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
Log Message:
---
add Concise tests for state var assignment
Add tests for
state $x = 1;
my $y = state $x = 1;
to check what context is allocated to the various ops. At the moment it
is actually wrong in places, and this commit captures that wrongness.
The next commit will fix this, and those diffs to the tests added in this
commit will help make it clear what has changed.
Commit: 6e575db0bff0341bdab5d7d5cba10f3496a34ea1
https://github.com/Perl/perl5/commit/6e575db0bff0341bdab5d7d5cba10f3496a34ea1
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M op.c
Log Message:
---
set context in 'state' expressions
The ops associated with a state variable declaration and initial
assignment weren't getting their context (GIMME) assigned.
Background:
state $x = ...;
gets compiled to something similar to
if (first_time)
$x = ...;
else
$x;
Except that the 'if' is performed by an OP_ONCE logop, which checks and
updates a flag in the pad, and branches to op_next or op_other as
appropriate.
During compilation, the context of the state expression wasn't being
passed on to the children of the OP_ONCE. So the assignment (optimised
into a padsv_store) and the padsv were left as UNKNOWN rather than VOID
or SCALAR as appropriate, as in these two examples:
state $x = 1; # should be void
$y = (state $x = 1); # should be scalar
This commit fixes that. Note that at the moment it makes no practical
difference, since the padsv/padsv_store ops don't currently change
their behaviour based on context, but that might change.
Commit: e498a32a9cb6a9c98e0c44b64241b51abe6435a1
https://github.com/Perl/perl5/commit/e498a32a9cb6a9c98e0c44b64241b51abe6435a1
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M gv.c
M op.c
M pp.c
Log Message:
---
Give OPpTARGET_MY ops real context
Perl has an optimisation whereby an op which returns the RHS of a scalar
assignment to a lexical, and which would normally store its result in
a PADTMP, instead skips the following PADSV and SASSIGN ops and assigns
to the lexical directly, instead of to the PADTMP. For example in
$lex = $a + $b;
the ops (in execution-order) would be changed from
add[t5] sK/2
gvsv[*lex] s
sassign vKS/2
nextstate(main 2 -e:1) v:{
to
add[$lex:1,2] sK/TARGMY,2
nextstate(main 2 -e:1) v:{
However, note that although that the add op is now essentially called in
void context, it is still marked as being in scalar context. This commit
changes it to be be marked as void, i.e.
add[$lex:1,2] vK/TARGMY,2
The main reason for this is to allow for future optimisations in
functions like pp_add(), which will be able to skip pushing the result
onto the stack in in void context. It just so happens that scalar
assignments to lexical vars are typically in void context.
However, since this is a visible change from the perspective of modules
which examine ops or optrees, I'll leave doing any optimisations until
later, in case this commit needs to be reverted.
The main things this commit had to fix up following the change were:
- still call overload methods in scalar context, even though the op is
now marked as void;
- not issuing "useless use of add in void context" style warnings on
such ops;
- making pp_push and pp_unshift still set TARG in void context
No matter whether the op's context is marked as scalar or as void, some
parts of perl will misunderstand, and will need to be special-cased
(since the op is really both, depending on your perspective). So this
commit changes the burden of the special-casing code to be in the
non-hot code paths, like during complication or when calling out to an
overload method.
Commit: eb5569f01a08008eaa45bbc5978da9607199046a
https://github.com/Perl/perl5/commit/eb5569f01a08008eaa45bbc5978da9607199046a
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M ext/B/t/optree_varinit.t
M peep.c
M pp_hot.c
M t/perf/opcount.t
Log Message:
---
OP_PADSV_STORE: only in void context
For the optimisation which converts $lex = expr into an OP_PADSV_STORE
op, only optimise if the scalar assign is in VOID context.
This allows us to stop pp_padsv_store() from uselessly pushing the
result onto the stack, only to be immediately popped again by the
following nextstate or unstack op. This becomes more important on
PERL_RC_STACK builds, as each push or pop involves manipulating the SV's
reference count.
I'm working on t
[Perl/perl5] 2100da: perlguts: fix ref count in tie() example
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 2100da0d758d65f39a3c82feb2c8991dbad7a821 https://github.com/Perl/perl5/commit/2100da0d758d65f39a3c82feb2c8991dbad7a821 Author: David Mitchell Date: 2024-01-03 (Wed, 03 Jan 2024) Changed paths: M pod/perlguts.pod Log Message: --- perlguts: fix ref count in tie() example Spotted by Marcel Telka.
[Perl/perl5]
Branch: refs/heads/davem/rc6 Home: https://github.com/Perl/perl5
[Perl/perl5] 6d1334: pp_sort: fix leak in PERL_RC_STACK inline sorting
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 6d1334c5cd9c5a8150747d54de714d03a6141f38
https://github.com/Perl/perl5/commit/6d1334c5cd9c5a8150747d54de714d03a6141f38
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M pp_sort.c
Log Message:
---
pp_sort: fix leak in PERL_RC_STACK inline sorting
For the optimised case where the src and dst are both the same array,
e.g.
@a = sort { ... } @a;
pp_sort() optimises this. When the code was modified to run under
PERL_RC_STACK, I introduced a leak: all the SVs on the stack after
sorting were then stored in the array and their ref counts incremented,
then the stack pointer was reset *without* decrementing the ref count of
each SV. So every SV in the array by the time pp_sort() returned had a
reference count one too high.
The fix is trivial - don't bump the ref counts when storing them in
the array.
Commit: 9c4b36214a66fdba52027f881d6619e1f9a0d15a
https://github.com/Perl/perl5/commit/9c4b36214a66fdba52027f881d6619e1f9a0d15a
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M op.c
M t/op/svleak.t
Log Message:
---
fix leak in list const folding under PERL_RC_STACK
S_gen_constant_list() wasn't taking account of the stack possibly being
reference-counted, and so when a list was being constant-folded into an
AV, that AV would leak, such as
while (1) { my $x = eval '\(1..3)'; }
Commit: 7184c7cb9d22e1849493d74272451de21703d71c
https://github.com/Perl/perl5/commit/7184c7cb9d22e1849493d74272451de21703d71c
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M pp_ctl.c
M t/op/svleak.t
Log Message:
---
fix obscure leak in sort { block } ...
This only leaked on PERL_RC_STACK builds, and only in the relatively
rare code path of a sort block which included a nested scope (such as
a for loop), and which then used 'return' to return the value.
Commit: 48cac15890ee29400bff9bb1e0c940997f1505b1
https://github.com/Perl/perl5/commit/48cac15890ee29400bff9bb1e0c940997f1505b1
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M pp_ctl.c
Log Message:
---
fix minor leak under use feature 'module_true'
Under PERL_RC_STACK builds, any return value from the module, i.e.
the
1;
or other final statement value, would leak.
Commit: 6ca3ba049e69f7b8d67362ce4fac7b812a47ee1f
https://github.com/Perl/perl5/commit/6ca3ba049e69f7b8d67362ce4fac7b812a47ee1f
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M sv.c
Log Message:
---
Resurrect immortals before checking for SvTEMP()
sv_clear() and sv_free2() both do, in this order, (simplified):
#ifdef DEBUGGING
if (SvTEMP(sv))
Perl_ck_warner_d(..., Attempt to free temp prematurely",...);
#endif
if (SvIMMORTAL(sv))
SvREFCNT(sv) = SvREFCNT_IMMORTAL
Now, it so happens that under DEBUGGING PERL_RC_STACK builds,
a) immortals such s PL_sv_undef have their refcount set to only 10 to
deliberately trigger the edge case of them being freed more often;
b) PERL_RC_STACK builds increasingly don't bother to increment the
reference counts of immortals when pushing them on the stack - this
saves a bit of time, and just means that once every two billion times on
normal builds the ref count drops to zero and sv_clear() sets it back to
SvREFCNT_IMMORTAL.
The combination of these has suddenly made it much more likely that
an immortal on the stack which has also been mortalised, will be passed
to sv_clear() and thus spuriously output the warning message.
So this commit swaps the order of the checks.
In the SvIMMORTAL() branch, it now also turns off SvTEMP.
Commit: 7f04cfc05d1d08fcba13a426ea4da76216c707cf
https://github.com/Perl/perl5/commit/7f04cfc05d1d08fcba13a426ea4da76216c707cf
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
Changed paths:
M embed.fnc
M embed.h
M inline.h
M pod/perlguts.pod
M proto.h
Log Message:
---
add _IMM variants to the rpp_foo() fns
These new function variants assume that the item being put on the stack
is one of the immortals (PL_sv_undef/yes/no/zero), and so skips
incrementing their reference count. This is for a minor efficiency
saving, rather than being necessary for correct functioning of the code.
This commit also tidies up a few of the related rpp_ functions: in
particular moving asserts out of the PERL_RC_STACK-only code into the
general code: an rpp_foo_NN() function should assert fail on a null SV
regardless of whether perl has been compiled under PERL_RC_STACK or not.
Commit: b6f2485657db9591ba249dc917047dbd11b373cf
https://github.com/Perl/perl5/commit/b6f2485657db9591ba249dc917047dbd11b373cf
Author: David Mitchell
Date: 2024-01-03 (Wed, 03 Jan 2024)
[Perl/perl5] 50fa09: xsubpp.PL: add code comments saying what it does
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 50fa0906cafc0e8c5309e293c2c2ded4d50a9e25 https://github.com/Perl/perl5/commit/50fa0906cafc0e8c5309e293c2c2ded4d50a9e25 Author: David Mitchell Date: 2023-12-23 (Sat, 23 Dec 2023) Changed paths: M utils/xsubpp.PL Log Message: --- xsubpp.PL: add code comments saying what it does
[Perl/perl5] e04a74: pp_sort: fix leak in PERL_RC_STACK inline sorting
Branch: refs/heads/davem/rc6
Home: https://github.com/Perl/perl5
Commit: e04a740c04fab860750eea2d02ba23295760dca8
https://github.com/Perl/perl5/commit/e04a740c04fab860750eea2d02ba23295760dca8
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M pp_sort.c
Log Message:
---
pp_sort: fix leak in PERL_RC_STACK inline sorting
For the optimised case where the src and dst are both the same array,
e.g.
@a = sort { ... } @a;
pp_sort() optimises this. When the code was modified to run under
PERL_RC_STACK, I introduced a leak: all the SVs on the stack after
sorting were then stored in the array and their ref counts incremented,
then the stack pointer was reset *without* decrementing the ref count of
each SV. So every SV in the array by the time pp_sort() returned had a
reference count one too high.
The fix is trivial - don't bump the ref counts when storing them in
the array.
Commit: a1f480c6704aeb291a8a2188528e9ac43a1fae7f
https://github.com/Perl/perl5/commit/a1f480c6704aeb291a8a2188528e9ac43a1fae7f
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M op.c
M t/op/svleak.t
Log Message:
---
fix leak in list const folding under PERL_RC_STACK
S_gen_constant_list() wasn't taking account of the stack possibly being
reference-counted, and so when a list was being constant-folded into an
AV, that AV would leak, such as
while (1) { my $x = eval '\(1..3)'; }
Commit: 54ca800a04128b2805ad27b3efa71db33575817e
https://github.com/Perl/perl5/commit/54ca800a04128b2805ad27b3efa71db33575817e
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M pp_ctl.c
M t/op/svleak.t
Log Message:
---
fix obscure leak in sort { block } ...
This only leaked on PERL_RC_STACK builds, and only in the relatively
rare code path of a sort block which included a nested scope (such as
a for loop), and which then used 'return' to return the value.
Commit: 6013fb43426b5830d237a921196d01f52d2ebad9
https://github.com/Perl/perl5/commit/6013fb43426b5830d237a921196d01f52d2ebad9
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M pp_ctl.c
Log Message:
---
fix minor leak under use feature 'module_true'
Under PERL_RC_STACK builds, any return value from the module, i.e.
the
1;
or other final statement value, would leak.
Commit: cceb23643602c0deb0afb8608b6083683c56c201
https://github.com/Perl/perl5/commit/cceb23643602c0deb0afb8608b6083683c56c201
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M sv.c
Log Message:
---
Resurrect immortals before checking for SvTEMP()
sv_clear() and sv_free2() both do, in this order, (simplified):
#ifdef DEBUGGING
if (SvTEMP(sv))
Perl_ck_warner_d(..., Attempt to free temp prematurely",...);
#endif
if (SvIMMORTAL(sv))
SvREFCNT(sv) = SvREFCNT_IMMORTAL
Now, it so happens that under DEBUGGING PERL_RC_STACK builds,
a) immortals such s PL_sv_undef have their refcount set to only 10 to
deliberately trigger the edge case of them being freed more often;
b) PERL_RC_STACK builds increasingly don't bother to increment the
reference counts of immortals when pushing them on the stack - this
saves a bit of time, and just means that once every two billion times on
normal builds the ref count drops to zero and sv_clear() sets it back to
SvREFCNT_IMMORTAL.
The combination of these has suddenly made it much more likely that
an immortal on the stack which has also been mortalised, will be passed
to sv_clear() and thus spuriously output the warning message.
So this commit swaps the order of the checks.
In the SvIMMORTAL() branch, it now also turns off SvTEMP.
Commit: 6436e75e681c655cf976622c31547b7f85fc2f16
https://github.com/Perl/perl5/commit/6436e75e681c655cf976622c31547b7f85fc2f16
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 2023)
Changed paths:
M embed.fnc
M embed.h
M inline.h
M pod/perlguts.pod
M proto.h
Log Message:
---
add _IMM variants to the rpp_foo() fns
These new function variants assume that the item being put on the stack
is one of the immortals (PL_sv_undef/yes/no/zero), and so skips
incrementing their reference count. This is for a minor efficiency
saving, rather than being necessary for correct functioning of the code.
This commit also tidies up a few of the related rpp_ functions: in
particular moving asserts out of the PERL_RC_STACK-only code into the
general code: an rpp_foo_NN() function should assert fail on a null SV
regardless of whether perl has been compiled under PERL_RC_STACK or not.
Commit: e6e89fe1e3a165fa7867501d992d7ec9ea778218
https://github.com/Perl/perl5/commit/e6e89fe1e3a165fa7867501d992d7ec9ea778218
Author: David Mitchell
Date: 2023-12-21 (Thu, 21 Dec 202
[Perl/perl5] c97221: fix AUTHORS
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: c97221f5af93a24091393dbdaa7c2191dc0eaffb https://github.com/Perl/perl5/commit/c97221f5af93a24091393dbdaa7c2191dc0eaffb Author: David Mitchell Date: 2023-12-13 (Wed, 13 Dec 2023) Changed paths: M AUTHORS Log Message: --- fix AUTHORS I made the mistake of allowing github to merge my commit.
[Perl/perl5]
Branch: refs/heads/davem/mark_sweep Home: https://github.com/Perl/perl5
[Perl/perl5] d3f30b: add sv_mark_arenas() and sv_sweep_arenas()
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: d3f30b5b431b1a44687eeb879d3082eda5c274b0 https://github.com/Perl/perl5/commit/d3f30b5b431b1a44687eeb879d3082eda5c274b0 Author: David Mitchell Date: 2023-12-13 (Wed, 13 Dec 2023) Changed paths: M embed.fnc M embed.h M pod/perlhacktips.pod M proto.h M sv.c Log Message: --- add sv_mark_arenas() and sv_sweep_arenas() These two functions can be used to help identify which SVs have leaked. See the new section in perlhacktips for full details, but basically the first function sets the SVf_BREAK flag on all existing SVs, while the second lists any SVs without that flag set (and so are likely candidates for having leaked).
[Perl/perl5] 2f3b84: add sv_mark_arenas() and sv_sweep_arenas()
Branch: refs/heads/davem/mark_sweep Home: https://github.com/Perl/perl5 Commit: 2f3b84bbd0d68bf022b751060c922e3af21076f4 https://github.com/Perl/perl5/commit/2f3b84bbd0d68bf022b751060c922e3af21076f4 Author: David Mitchell Date: 2023-12-08 (Fri, 08 Dec 2023) Changed paths: M embed.fnc M embed.h M pod/perlhacktips.pod M proto.h M sv.c Log Message: --- add sv_mark_arenas() and sv_sweep_arenas() These two functions can be used to help identify which SVs have leaked. See the new section in perlhacktips for full details, but basically the first function sets the SVf_BREAK flag on all existing SVs, while the second lists any SVs without that flag set (and so are likely candidates for having leaked).
[Perl/perl5]
Branch: refs/heads/davem/rc5 Home: https://github.com/Perl/perl5
[Perl/perl5] 594c45: make RC-stack-aware: unwrap pp_index()
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 594c45d643751f7afe1092bf6b2bec22a912f135 https://github.com/Perl/perl5/commit/594c45d643751f7afe1092bf6b2bec22a912f135 Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap pp_index() Remove the temporary wrapper from pp_index() Commit: 591200f6f0f3257838efb8d5103b955e84db6ffd https://github.com/Perl/perl5/commit/591200f6f0f3257838efb8d5103b955e84db6ffd Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M dist/IO/IO.xs Log Message: --- IO::getline(): use CALLRUNOPS This XS function calls Perl_pp_readline() directly. Instead, invoke the op via CALLRUNOPS(): the run loop (that will just run a single op) can handle the case of the caller having a non-reference-counted stack, but when the ops it calls are expecting a reference-counted stack. Perl_pp_readline() will (in a few commits' time) indeed be expecting a reference-counted stack. Commit: d25231bc219ffc858cb4291da9ca933e958dcf41 https://github.com/Perl/perl5/commit/d25231bc219ffc858cb4291da9ca933e958dcf41 Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M dist/IO/IO.xs Log Message: --- IO::getline() handle OPf_STACKED better When calling Perl_pp_readline(), only set OPf_STACKED, and only create a dummy stacked target, when in scalar context. getline() had been sort of getting away with always setting it, but the next commit but one will make pp_readline() more strict about its flag handling (basically adding lots of asserts and only processing the target when OPf_STACKED is set). This change has been wrapped in a version #ifdef, as on older perls pp_readline() will unconditionally try to retrieve the targ from the pad if OPf_STACKED isn't set, and probably crash. Note that until the next commit but one, this commit will probably fail t/io_getline.t. Commit: 14c47929512aa30191dca1f037cc3584580023c8 https://github.com/Perl/perl5/commit/14c47929512aa30191dca1f037cc3584580023c8 Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M pp.h M pp_hot.c M pp_sys.c Log Message: --- expand tryAMAGICunTARGETlist() macro This long macro is only used in two places (pp_readline and pp_glob). Expand the contents of this macro directly in those two functions. This will make it easier to individually unwrap (i.e. remove PP_wrapped()) those two functions. Shouldn't be any functional change. Commit: 651f4b6c76d59d6258fe672000c6ce9a23c993a1 https://github.com/Perl/perl5/commit/651f4b6c76d59d6258fe672000c6ce9a23c993a1 Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M gv.c M pp.c M pp_hot.c M pp_sys.c Log Message: --- make RC-stack-aware: pp_readline(), pp_glob() etc Remove the temporary wrappers from: pp_readline() pp_rcatline() pp_glob() pp_rv2gv() and dependent functions. This started out as an attempt to unwrap the simple pp_rv2gv() function. But pp_readline() calls pp_rv2gv() too, so that had to be unwrapped too. Then the bulk of pp_readline()'s implementation is done by do_readline(), so that had to be updated too. But pp_rcatline() and pp_glob() also call out to do_readline(), so they had to be fixed too. And pp_glob() outsources most of its work to the XS module File::Glob, so calling that had to be wrapped to handle a non-refcounted stack in the XS code. Then it turns out that code in IO.xs calls pp_readline() directly and needed tweaking. So now its a large commit that updates nearly everything in one big go. While fixing up everything, I took the opportunity to add many code comments and asserts to better document what these various functions do, and what args they expect on the stack under what flag conditions. The op_flag processing is now more strict, so potentially other code which directly fakes up an op with sloppy flag settings and calls one of these pp functions directly might now trigger an assert failure. (See the fix-up to IO.xs a couple of commits ago for an example.) Commit: 99e4f4b1c4bc11fc21660d3dcd3c6eb584361c54 https://github.com/Perl/perl5/commit/99e4f4b1c4bc11fc21660d3dcd3c6eb584361c54 Author: David Mitchell Date: 2023-12-06 (Wed, 06 Dec 2023) Changed paths: M pp.h Log Message: --- remove unused tryAMAGICunTARGETlist macro This macro was originally only used in two places in core (pp_readline and pp_glob), and nowhere on CPAN. The last few commits inlined those only two usages, then modified the functions using that code to be PERL_RC_STACK-aware. Since the macro is now unused, and is the old obsolete non-PERL_RC_STACK code, this commit just deletes it. Commit: 49e6c78e46b366d68f0bef59674dc9dfaed3d131 https://gith
[Perl/perl5] 877112: make RC-stack-aware: unwrap pp_index()
Branch: refs/heads/davem/rc5 Home: https://github.com/Perl/perl5 Commit: 877112385c9ef69497937fc9969f9040732df61b https://github.com/Perl/perl5/commit/877112385c9ef69497937fc9969f9040732df61b Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap pp_index() Remove the temporary wrapper from pp_index() Commit: 3b66035813f06f9fbfec11787ff431237478e2db https://github.com/Perl/perl5/commit/3b66035813f06f9fbfec11787ff431237478e2db Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M dist/IO/IO.xs Log Message: --- IO::getline(): use CALLRUNOPS This XS function calls Perl_pp_readline() directly. Instead, invoke the op via CALLRUNOPS(): the run loop (that will just run a single op) can handle the case of the caller having a non-reference-counted stack, but when the ops it calls are expecting a reference-counted stack. Perl_pp_readline() will (in a few commits' time) indeed be expecting a reference-counted stack. Commit: ebb1b1fd72233a35d8315fef16ab317ccd8a16de https://github.com/Perl/perl5/commit/ebb1b1fd72233a35d8315fef16ab317ccd8a16de Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M dist/IO/IO.xs Log Message: --- IO::getline() handle OPf_STACKED better When calling Perl_pp_readline(), only set OPf_STACKED, and only create a dummy stacked target, when in scalar context. getline() had been sort of getting away with always setting it, but the next commit but one will make pp_readline() more strict about its flag handling (basically adding lots of asserts and only processing the target when OPf_STACKED is set). This change has been wrapped in a version #ifdef, as on older perls pp_readline() will unconditionally try to retrieve the targ from the pad if OPf_STACKED isn't set, and probably crash. Note that until the next commit but one, this commit will probably fail t/io_getline.t. Commit: eb7b2708f8cd2c8ea73b42ef0bb98489bef6d17a https://github.com/Perl/perl5/commit/eb7b2708f8cd2c8ea73b42ef0bb98489bef6d17a Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M pp.h M pp_hot.c M pp_sys.c Log Message: --- expand tryAMAGICunTARGETlist() macro This long macro is only used in two places (pp_readline and pp_glob). Expand the contents of this macro directly in those two functions. This will make it easier to individually unwrap (i.e. remove PP_wrapped()) those two functions. Shouldn't be any functional change. Commit: ccf9d66e8acd5f1ef2651959670dcb707b51dca6 https://github.com/Perl/perl5/commit/ccf9d66e8acd5f1ef2651959670dcb707b51dca6 Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M gv.c M pp.c M pp_hot.c M pp_sys.c Log Message: --- make RC-stack-aware: pp_readline(), pp_glob() etc Remove the temporary wrappers from: pp_readline() pp_rcatline() pp_glob() pp_rv2gv() and dependent functions. This started out as an attempt to unwrap the simple pp_rv2gv() function. But pp_readline() calls pp_rv2gv() too, so that had to be unwrapped too. Then the bulk of pp_readline()'s implementation is done by do_readline(), so that had to be updated too. But pp_rcatline() and pp_glob() also call out to do_readline(), so they had to be fixed too. And pp_glob() outsources most of its work to the XS module File::Glob, so calling that had to be wrapped to handle a non-refcounted stack in the XS code. Then it turns out that code in IO.xs calls pp_readline() directly and needed tweaking. So now its a large commit that updates nearly everything in one big go. While fixing up everything, I took the opportunity to add many code comments and asserts to better document what these various functions do, and what args they expect on the stack under what flag conditions. The op_flag processing is now more strict, so potentially other code which directly fakes up an op with sloppy flag settings and calls one of these pp functions directly might now trigger an assert failure. (See the fix-up to IO.xs a couple of commits ago for an example.) Commit: 408102c3f022dd757533fafcd9e5c170d89f6542 https://github.com/Perl/perl5/commit/408102c3f022dd757533fafcd9e5c170d89f6542 Author: David Mitchell Date: 2023-12-05 (Tue, 05 Dec 2023) Changed paths: M pp.h Log Message: --- remove unused tryAMAGICunTARGETlist macro This macro was originally only used in two places in core (pp_readline and pp_glob), and nowhere on CPAN. The last few commits inlined those only two usages, then modified the functions using that code to be PERL_RC_STACK-aware. Since the macro is now unused, and is the old obsolete non-PERL_RC_STACK code, this commit just deletes it. Compare: https://github.com/Perl/perl5/compare/877112385c9e%5E...4
[Perl/perl5]
Branch: refs/heads/davem/rc4 Home: https://github.com/Perl/perl5
[Perl/perl5] 08368a: document ref assignment in list context
Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 08368a773f179335566e09096be6e015368237d1
https://github.com/Perl/perl5/commit/08368a773f179335566e09096be6e015368237d1
Author: David Mitchell
Date: 2023-12-04 (Mon, 04 Dec 2023)
Changed paths:
M pod/perlref.pod
Log Message:
---
document ref assignment in list context
The 'refaliasing' feature, whereby assigning to a literal reference
causes an aliasing operation (e.g. \$x = \...) didn't document what was
returned if the assignment was done in list context.
This commit adds a basic summary to the docs.
See the thread http://nntp.perl.org/group/perl.perl5.porters/267074
for the discussion.
Commit: 823fcbfd95001ebd591a4b9c0c19b0e126f22d76
https://github.com/Perl/perl5/commit/823fcbfd95001ebd591a4b9c0c19b0e126f22d76
Author: David Mitchell
Date: 2023-12-04 (Mon, 04 Dec 2023)
Changed paths:
M t/op/lvref.t
Log Message:
---
add list context tests to t/op/lvref.t
Codify the existing behaviour of alias list assignment in list
context, e.g.
= ( (\$x, \$y, \(@a)) = () );
and
( (\$x, \$y, \(@a)) = () ) = ;
Whether the existing behaviour is sane is up for debate, but if
if we change it, it should be a deliberate choice, not an accidental
change not spotted by the existing tests.
Commit: b98a30fe2d2891321ee60dcd6b44ce6498a1f211
https://github.com/Perl/perl5/commit/b98a30fe2d2891321ee60dcd6b44ce6498a1f211
Author: David Mitchell
Date: 2023-12-04 (Mon, 04 Dec 2023)
Changed paths:
M t/op/lvref.t
Log Message:
---
add lvalue scalar alias tests to lvref.t
This is a compile-time error:
(\$x = \1) = \2;
However, the following is legal code, but is untested (the 'OPf_MOD'
branch in pp_refassign() is not triggered by the test suite):
f(\$x = \1);
So this commit adds some tests. It assumes that the above code is
equivalent to:
\$x = \1;
f(\$x);
Whether the existing behaviour is sane is up for debate, but if
if we change it, it should be a deliberate choice, not an accidental
change not spotted by the existing tests.
Commit: 313c8957d30780156be85d76909da6b1bfdbce27
https://github.com/Perl/perl5/commit/313c8957d30780156be85d76909da6b1bfdbce27
Author: David Mitchell
Date: 2023-12-04 (Mon, 04 Dec 2023)
Changed paths:
M ext/Hash-Util-FieldHash/t/02_function.t
Log Message:
---
Hash-Util-FieldHash: fixup test on PERL_RC_STACK
Hash::Util::FieldHash is an implementation of "inside out" objects,
where field values are stored in per-field hashes whose keys are the
numeric addresses of the objects, and whose values represent the value
of that field for a particular object.
The hashes are magic, in that they don't hold a reference to each
object, but automatically delete the relevant entry from the hash when
the object is freed. This is achieved internally with weak references
and a bunch of user magic attached to the hash and the object.
A test in 02_function.t checks that such a link in the magic hash to an
object is removed after the real object is freed. This test looked
something like:
$h{[]} = 123;
is(keys %h, 0);
which relied on the temp anon array being freed almost immediately and
triggering the hash delete. Now it turns out that OP_ANONLIST (and its
later optimisation, OP_EMPTYAVHV) return an SvTEMP RV. In the code
above, this means that [] gets freed at the start of the next statement
(by the freetmps() in pp_nextstate()), and all works as expected.
However, when pp_emptyavhv() is unwrapped in the next commit, on
PERL_RC_STACK builds it will skip mortalising the return result, and
just rely on the ref count from the stack to keep the RV alive as long
as needed. By "needed", this is only while the helem op is being
executed, and the temp array is thus freed at the end of the helem,
rather than at the end of the statement. This triggers the entry in the
hash being auto-deleted earlier, so when the next op, the scalar assign,
executes, it triggers a warning:
Useless assignment to a temporary at t/02_function.t line 121.
After a lot of faffing about trying to work out what was going on, I
concluded that the intent of the test could just as well be done by
creating a real array reference variable and to just undef it directly
after the hash assign.
(I.e. it took some time to convince myself that there wasn't a bug in
pp_emptyavhv, pp_sassign nor FieldHash.xs, and that just the test needed
fixing.)
Commit: 14403447b7488675c7d043c7d7325011727b3e45
https://github.com/Perl/perl5/commit/14403447b7488675c7d043c7d7325011727b3e45
Author: David Mitchell
Date: 2023-12-04 (Mon, 04 Dec 2023)
Changed paths:
M pp.c
M t/op/array.t
Log Message:
---
make RC-stack-aware: unwrap pp_emptyavhv()
Remove the temporary wrapper from pp_emptyavhv()
Also fix some tests in array.t, which were expecting a temp emp
[Perl/perl5] 5d65e3: document ref assignment in list context
Branch: refs/heads/davem/rc4
Home: https://github.com/Perl/perl5
Commit: 5d65e37772d3d0285455a64121f02e0745ded5ea
https://github.com/Perl/perl5/commit/5d65e37772d3d0285455a64121f02e0745ded5ea
Author: David Mitchell
Date: 2023-11-16 (Thu, 16 Nov 2023)
Changed paths:
M pod/perlref.pod
Log Message:
---
document ref assignment in list context
The 'refaliasing' feature, whereby assigning to a literal reference
causes an aliasing operation (e.g. \$x = \...) didn't document what was
returned if the assignment was done in list context.
This commit adds a basic summary to the docs.
See the thread http://nntp.perl.org/group/perl.perl5.porters/267074
for the discussion.
Commit: 64d8ebe65e8ce16c6075737d39c1a0ac6b4a1ecc
https://github.com/Perl/perl5/commit/64d8ebe65e8ce16c6075737d39c1a0ac6b4a1ecc
Author: David Mitchell
Date: 2023-11-16 (Thu, 16 Nov 2023)
Changed paths:
M t/op/lvref.t
Log Message:
---
add list context tests to t/op/lvref.t
Codify the existing behaviour of alias list assignment in list
context, e.g.
= ( (\$x, \$y, \(@a)) = () );
and
( (\$x, \$y, \(@a)) = () ) = ;
Whether the existing behaviour is sane is up for debate, but if
if we change it, it should be a deliberate choice, not an accidental
change not spotted by the existing tests.
Commit: 8b7d699fcc0d311eae10ad3e79521231f5983501
https://github.com/Perl/perl5/commit/8b7d699fcc0d311eae10ad3e79521231f5983501
Author: David Mitchell
Date: 2023-11-16 (Thu, 16 Nov 2023)
Changed paths:
M t/op/lvref.t
Log Message:
---
add lvalue scalar alias tests to lvref.t
This is a compile-time error:
(\$x = \1) = \2;
However, the following is legal code, but is untested (the 'OPf_MOD'
branch in pp_refassign() is not triggered by the test suite):
f(\$x = \1);
So this commit adds some tests. It assumes that the above code is
equivalent to:
\$x = \1;
f(\$x);
Whether the existing behaviour is sane is up for debate, but if
if we change it, it should be a deliberate choice, not an accidental
change not spotted by the existing tests.
Commit: 25d6d0ceb783c06f069ee01ea5bbc4731d08a3ca
https://github.com/Perl/perl5/commit/25d6d0ceb783c06f069ee01ea5bbc4731d08a3ca
Author: David Mitchell
Date: 2023-11-16 (Thu, 16 Nov 2023)
Changed paths:
M ext/Hash-Util-FieldHash/t/02_function.t
Log Message:
---
Hash-Util-FieldHash: fixup test on PERL_RC_STACK
Hash::Util::FieldHash is an implementation of "inside out" objects,
where field values are stored in per-field hashes whose keys are the
numeric addresses of the objects, and whose values represent the value
of that field for a particular object.
The hashes are magic, in that they don't hold a reference to each
object, but automatically delete the relevant entry from the hash when
the object is freed. This is achieved internally with weak references
and a bunch of user magic attached to the hash and the object.
A test in 02_function.t checks that such a link in the magic hash to an
object is removed after the real object is freed. This test looked
something like:
$h{[]} = 123;
is(keys %h, 0);
which relied on the temp anon array being freed almost immediately and
triggering the hash delete. Now it turns out that OP_ANONLIST (and its
later optimisation, OP_EMPTYAVHV) return an SvTEMP RV. In the code
above, this means that [] gets freed at the start of the next statement
(by the freetmps() in pp_nextstate()), and all works as expected.
However, when pp_emptyavhv() is unwrapped in the next commit, on
PERL_RC_STACK builds it will skip mortalising the return result, and
just rely on the ref count from the stack to keep the RV alive as long
as needed. By "needed", this is only while the helem op is being
executed, and the temp array is thus freed at the end of the helem,
rather than at the end of the statement. This triggers the entry in the
hash being auto-deleted earlier, so when the next op, the scalar assign,
executes, it triggers a warning:
Useless assignment to a temporary at t/02_function.t line 121.
After a lot of faffing about trying to work out what was going on, I
concluded that the intent of the test could just as well be done by
creating a real array reference variable and to just undef it directly
after the hash assign.
(I.e. it took some time to convince myself that there wasn't a bug in
pp_emptyavhv, pp_sassign nor FieldHash.xs, and that just the test needed
fixing.)
Commit: 23ec0babb8eda05b5a30fcd4cea236d44bea2f51
https://github.com/Perl/perl5/commit/23ec0babb8eda05b5a30fcd4cea236d44bea2f51
Author: David Mitchell
Date: 2023-11-16 (Thu, 16 Nov 2023)
Changed paths:
M pp.c
M t/op/array.t
Log Message:
---
make RC-stack-aware: unwrap pp_emptyavhv()
Remove the temporary wrapper from pp_emptyavhv()
Also fix some tests in array.t, which were expecting a temp
[Perl/perl5] bb3665: perldelta for 7bcd18ae82e
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: bb3665a51415a1d1693a302d518106417433b297 https://github.com/Perl/perl5/commit/bb3665a51415a1d1693a302d518106417433b297 Author: David Mitchell Date: 2023-09-19 (Tue, 19 Sep 2023) Changed paths: M pod/perldelta.pod Log Message: --- perldelta for 7bcd18ae82e
[Perl/perl5]
Branch: refs/heads/davem/sm_overload Home: https://github.com/Perl/perl5
[Perl/perl5] 549d65: smartmatch: $obj ~~ $scalar: one item in list cxt
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 549d65685e57ebefebbb7d8766e346fa2e33fc7d https://github.com/Perl/perl5/commit/549d65685e57ebefebbb7d8766e346fa2e33fc7d Author: David Mitchell Date: 2023-09-19 (Tue, 19 Sep 2023) Changed paths: M lib/overload.t M pp_ctl.c Log Message: --- smartmatch: $obj ~~ $scalar: one item in list cxt GH ##21477 My recent commit, v5.39.2-101-g987819ee34, "make RC-stack-aware: unwrap startmatch [sic] and misc" introduced a bug which broke Lingua::EN::Inflexion. This was because the code path for handling overloaded objects of the form ($obj ~~ $scalar) was re-pushing the original args onto the stack before calling the overload method, which was unnecessary. This meant that in list context, rather than returning the one-element list (Y/N), it was returning the three-element list ($obj, $scalar, Y/N). This commit fixes that.
[Perl/perl5] 915deb: smartmatch: $obj ~~ $scalar: one item in list cxt
Branch: refs/heads/davem/sm_overload Home: https://github.com/Perl/perl5 Commit: 915deba6cfc5cb6b5c538e0c3986e6c9ac9a4c8d https://github.com/Perl/perl5/commit/915deba6cfc5cb6b5c538e0c3986e6c9ac9a4c8d Author: David Mitchell Date: 2023-09-15 (Fri, 15 Sep 2023) Changed paths: M lib/overload.t M pp_ctl.c Log Message: --- smartmatch: $obj ~~ $scalar: one item in list cxt My recent commit, v5.39.2-101-g987819ee34, "make RC-stack-aware: unwrap startmatch [sic] and misc" introduced a bug which broke Lingua::EN::Inflexion. This was because the code path for handling overloaded objects of the form ($obj ~~ $scalar) was re-pushing the original args onto the stack before calling the overload method, which was unnecessary. This meant that in list context, rather than returning the one-element list (Y/N), it was returning the three-element list ($obj, $scalar, Y/N). This commit fixes that.
[Perl/perl5]
Branch: refs/heads/davem/rc3 Home: https://github.com/Perl/perl5
[Perl/perl5] 5d6500: threads->object(): handle no argument
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 5d6500d120bab334f9979cd64234506ec477b4f2 https://github.com/Perl/perl5/commit/5d6500d120bab334f9979cd64234506ec477b4f2 Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M dist/threads/threads.xs Log Message: --- threads->object(): handle no argument threads->object() without an argument is supposed to return undef. But before checking that there's no argument, the XS was actually accessing the argument. This went undetected for around 13 years, due to the fact that 1) likely nothing outside the test code in basic.t called it without an argument; 2) as long as any old SV pointer was still on the stack it would (probably) harmlessly access it and then return. I only spotted it due to the fact that a recent change to PERL_RC_STACK meant that the pointer one above the top of stack happened to be NULL. Commit: 2505eae6f1b390c067ba9b9c6e357b4110b5fcba https://github.com/Perl/perl5/commit/2505eae6f1b390c067ba9b9c6e357b4110b5fcba Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_replace_at() API function Commit: ebb199352e58d39ca085f74983e54e7ebccc41cd https://github.com/Perl/perl5/commit/ebb199352e58d39ca085f74983e54e7ebccc41cd Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_context() API function Commit: 987819ee340ef066ca55195bb1b5ba779af003ea https://github.com/Perl/perl5/commit/987819ee340ef066ca55195bb1b5ba779af003ea Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M pp.c M pp_ctl.c M pp_hot.c Log Message: --- make RC-stack-aware: unwrap startmatch and misc Remove the temporary wrappers from these pp() functions: pp_smartmatch pp_i_eq pp_eq pp_seq pp_match They had to be treated as one group since pp_smartmatch() tail calls the other four pp() functions. Commit: 28ace72af440195d8e4af5ec47a3ac9bb012eb6a https://github.com/Perl/perl5/commit/28ace72af440195d8e4af5ec47a3ac9bb012eb6a Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M pp_hot.c Log Message: --- make RC-stack-aware: unwrap pp_padsv_store() Remove the temporary wrapper from this unary pp() function. It should have been done at the same time as all the other hot unary ops, but I missed it. Commit: e594d9080c26a5c6a42d9b9cf367bff5b1acfba2 https://github.com/Perl/perl5/commit/e594d9080c26a5c6a42d9b9cf367bff5b1acfba2 Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M embed.fnc M pp_hot.c M pp_sys.c M proto.h Log Message: --- make RC-stack-aware: unwrap pp_print(),tied_method Remove the temporary wrapper from pp_print(). Also, update Perl_tied_method() to support both ref-counted-stack and non-ref-counted-stack callers. Initially pp_print() is the only RC caller of it. Perl_tied_method() was a bit of mess: undocumented and confusing. So also add some more code comments, and rename one of its parameters from 'sp' to 'mark' to better reflect that it points to the base of the argument list, not to the top. Commit: c2c1a363cf89a6855effeda1e9686d3d7c66321b https://github.com/Perl/perl5/commit/c2c1a363cf89a6855effeda1e9686d3d7c66321b Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: pp_anonlist, pp_av2arylen Remove the temporary wrapper from pp_anonlist() and update it to directly work in a refcounted-stack environment. In addition, fix a bug in (the already unwrapped) pp_av2arylen(), which only manifests itself in PERL_RC_STACK environments. In particular, this expression in lvalue context was triggering a premature free of the array: [1..10]->$#* Basically pp_av2arylen() pops the AV off the stack and replaces it with an SV with PERL_MAGIC_arylen which points back to the AV (and vice versa). The link back is weak, so nothing actually keeps the AV alive; previously, something else like the temps stack was keeping AV alive. So swap the weak/strong mg_ptrs around to make the problem go away. Commit: 074e89b2be5d1938d339164a0f6011cd49bae783 https://github.com/Perl/perl5/commit/074e89b2be5d1938d339164a0f6011cd49bae783 Author: David Mitchell Date: 2023-09-12 (Tue, 12 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap: pp_(kv)[ah]slice Remove the temporary wrappers from: pp_aslice() pp_hslice() pp_kvaslice() pp_kvhslice() Commit: bcd794669851c5218a5b5c1aea4
[Perl/perl5] 253be3: add rpp_replace_at() API function
Branch: refs/heads/davem/rc3 Home: https://github.com/Perl/perl5 Commit: 253be3248222778ec3d0c6d85b9c0fc8ee86670e https://github.com/Perl/perl5/commit/253be3248222778ec3d0c6d85b9c0fc8ee86670e Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_replace_at() API function Commit: d00f98795a4dcdfd323a0ed5ab6d301031ab16d3 https://github.com/Perl/perl5/commit/d00f98795a4dcdfd323a0ed5ab6d301031ab16d3 Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M dist/threads/threads.xs Log Message: --- threads->object(): handle no argument threads->object() without an argument is supposed to return undef. But before checking that there's no argument, the XS was actually accessing the argument. This went undetected for around 13 years, due to the fact that 1) likely nothing outside the test code in basic.t called it without an argument; 2) as long as any old SV pointer was still on the stack it would (probably) harmlessly access it and then return. I only spotted it due to the fact that a recent change to PERL_RC_STACK meant that the pointer one above the top of stack happened to be NULL. Commit: 401f18ce0246a0f54bf7fa6b85ed75b3513a75ee https://github.com/Perl/perl5/commit/401f18ce0246a0f54bf7fa6b85ed75b3513a75ee Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_context() API function Commit: 39d32d0a07d2b3e21150e45649b2e064ea4ab499 https://github.com/Perl/perl5/commit/39d32d0a07d2b3e21150e45649b2e064ea4ab499 Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M pp.c M pp_ctl.c M pp_hot.c Log Message: --- make RC-stack-aware: unwrap startmatch and misc Remove the temporary wrappers from these pp() functions: pp_smartmatch pp_i_eq pp_eq pp_seq pp_match They had to be treated as one group since pp_smartmatch() tail calls the other four pp() functions. Commit: 215ea980d1ffae2df32d63031b9ed241fee15b8d https://github.com/Perl/perl5/commit/215ea980d1ffae2df32d63031b9ed241fee15b8d Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M pp_hot.c Log Message: --- make RC-stack-aware: unwrap pp_padsv_store() Remove the temporary wrapper from this unary pp() function. It should have been done at the same time as all the other hot unary ops, but I missed it. Commit: b1559ebafb2f7ff0bd8bb2f286663179170f7a34 https://github.com/Perl/perl5/commit/b1559ebafb2f7ff0bd8bb2f286663179170f7a34 Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M embed.fnc M pp_hot.c M pp_sys.c M proto.h Log Message: --- make RC-stack-aware: unwrap pp_print(),tied_method Remove the temporary wrapper from pp_print(). Also, update Perl_tied_method() to support both ref-counted-stack and non-ref-counted-stack callers. Initially pp_print() is the only RC caller of it. Perl_tied_method() was a bit of mess: undocumented and confusing. So also add some more code comments, and rename one of its parameters from 'sp' to 'mark' to better reflect that it points to the base of the argument list, not to the top. Commit: 07fb468e789015f20d7959d7d079aff757a6daca https://github.com/Perl/perl5/commit/07fb468e789015f20d7959d7d079aff757a6daca Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: pp_anonlist, pp_av2arylen Remove the temporary wrapper from pp_anonlist() and update it to directly work in a refcounted-stack environment. In addition, fix a bug in (the already unwrapped) pp_av2arylen(), which only manifests itself in PERL_RC_STACK environments. In particular, this expression in lvalue context was triggering a premature free of the array: [1..10]->$#* Basically pp_av2arylen() pops the AV off the stack and replaces it with an SV with PERL_MAGIC_arylen which points back to the AV (and vice versa). The link back is weak, so nothing actually keeps the AV alive; previously, something else like the temps stack was keeping AV alive. So swap the weak/strong mg_ptrs around to make the problem go away. Commit: 8d5561e5b0da75c5200e4b208042084e9c7dbd18 https://github.com/Perl/perl5/commit/8d5561e5b0da75c5200e4b208042084e9c7dbd18 Author: David Mitchell Date: 2023-09-11 (Mon, 11 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap: pp_(kv)[ah]slice Remove the temporary wrappers from: pp_aslice() pp_hslice() pp_kvaslice() pp_kvhslice() Commit: 5dcff307731add12b371587
[Perl/perl5] 8f6713: add rpp_replace_at() API function
Branch: refs/heads/davem/rc3 Home: https://github.com/Perl/perl5 Commit: 8f6713e525a992c8cc1d80b7b69e23f774511f64 https://github.com/Perl/perl5/commit/8f6713e525a992c8cc1d80b7b69e23f774511f64 Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_replace_at() API function Commit: 095a29e2f15f1a44478dbc10f08c84d65126fb02 https://github.com/Perl/perl5/commit/095a29e2f15f1a44478dbc10f08c84d65126fb02 Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M embed.fnc M embed.h M inline.h M pod/perlguts.pod M proto.h Log Message: --- add rpp_context() API function Commit: f4b013698fc3e7fe5257dd84c5035c2c6ad5bb62 https://github.com/Perl/perl5/commit/f4b013698fc3e7fe5257dd84c5035c2c6ad5bb62 Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp.c M pp_ctl.c M pp_hot.c Log Message: --- make RC-stack-aware: unwrap startmatch and misc Remove the temporary wrappers from these pp() functions: pp_smartmatch pp_i_eq pp_eq pp_seq pp_match They had to be treated as one group since pp_smartmatch() tail calls the other four pp() functions. Commit: 7d0ef3192bcb0f8a26b2f84af35975154540fdaa https://github.com/Perl/perl5/commit/7d0ef3192bcb0f8a26b2f84af35975154540fdaa Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp_hot.c Log Message: --- make RC-stack-aware: unwrap pp_padsv_store() Remove the temporary wrapper from this unary pp() function. It should have been done at the same time as all the other hot unary ops, but I missed it. Commit: 554348a381d77da3906783513ba5c92514e60b9d https://github.com/Perl/perl5/commit/554348a381d77da3906783513ba5c92514e60b9d Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M embed.fnc M pp_hot.c M pp_sys.c M proto.h Log Message: --- make RC-stack-aware: unwrap pp_print(),tied_method Remove the temporary wrapper from pp_print(). Also, update Perl_tied_method() to support both ref-counted-stack and non-ref-counted-stack callers. Initially pp_print() is the only RC caller of it. Perl_tied_method() was a bit of mess: undocumented and confusing. So also add some more code comments, and rename one of its parameters from 'sp' to 'mark' to better reflect that it points to the base of the argument list, not to the top. Commit: 4df9f3a6ed6e265beae78f1587af0e88d3df76ad https://github.com/Perl/perl5/commit/4df9f3a6ed6e265beae78f1587af0e88d3df76ad Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: pp_anonlist, pp_av2arylen Remove the temporary wrapper from pp_anonlist() and update it to directly work in a refcounted-stack environment. In addition, fix a bug in (the already unwrapped) pp_av2arylen(), which only manifests itself in PERL_RC_STACK environments. In particular, this expression in lvalue context was triggering a premature free of the array: [1..10]->$#* Basically pp_av2arylen() pops the AV off the stack and replaces it with an SV with PERL_MAGIC_arylen which points back to the AV (and vice versa). The link back is weak, so nothing actually keeps the AV alive; previously, something else like the temps stack was keeping AV alive. So swap the weak/strong mg_ptrs around to make the problem go away. Commit: 3a3935e9c065e343f6d4797520373bad06118154 https://github.com/Perl/perl5/commit/3a3935e9c065e343f6d4797520373bad06118154 Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap: pp_(kv)[ah]slice Remove the temporary wrappers from: pp_aslice() pp_hslice() pp_kvaslice() pp_kvhslice() Commit: 1716877ea558fe18073150130dbc706690e9b99b https://github.com/Perl/perl5/commit/1716877ea558fe18073150130dbc706690e9b99b Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp_hot.c Log Message: --- make RC-stack-aware: unwrap pp_join() Remove the temporary wrapper from pp_join() Commit: 796a53cc6619718a889d594fe4edc1a06c49c6b3 https://github.com/Perl/perl5/commit/796a53cc6619718a889d594fe4edc1a06c49c6b3 Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp.c Log Message: --- make RC-stack-aware: unwrap pp_push() Remove the temporary wrapper from pp_push() Commit: e30412b2d1da8efb398b47e41cbb378539aad80e https://github.com/Perl/perl5/commit/e30412b2d1da8efb398b47e41cbb378539aad80e Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths:
[Perl/perl5] 1ff13a: pp_caller/@DB::args: fix fail under -DPERL_POISON
Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: 1ff13a08be65e3dd2618f9a2abea3e4e2990d89c https://github.com/Perl/perl5/commit/1ff13a08be65e3dd2618f9a2abea3e4e2990d89c Author: David Mitchell Date: 2023-09-08 (Fri, 08 Sep 2023) Changed paths: M pp_ctl.c Log Message: --- pp_caller/@DB::args: fix fail under -DPERL_POISON v5.39.1-335-gd2cddbe1df added a fix and test when copying elements of a sub's arg into @DB::args, to skip freed SVs, i.e. ones whose RC==0. However, under -DPERL_POISON builds, such SVs can have a "reference count" of 0xabababab... . So in addition, check for SvIS_FREED(). This fixes recent smoke failures under -DPERL_POISON.
