Branch: refs/heads/blead Home: https://github.com/Perl/perl5 Commit: a0911be9ee3a73417e7f1dbb6b168db70f3d737e https://github.com/Perl/perl5/commit/a0911be9ee3a73417e7f1dbb6b168db70f3d737e Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022)
Changed paths: M Porting/deparse-skips.txt Log Message: ----------- Porting/deparse-skips.txt: update Math-Big* v5.35.5-35-g6853e8af3b made some big changes to the various big math test files. Update the Deparse test skip list to account for all the test file renames, changes etc. Commit: e25d08b5518093e0dbaf56e9a80f9a7629eee359 https://github.com/Perl/perl5/commit/e25d08b5518093e0dbaf56e9a80f9a7629eee359 Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M lib/B/Deparse.pm M lib/B/Deparse.t Log Message: ----------- Deparse: honour custom warnings categories Perl's warning system is based around a bitmask string, with 2 bits per warning category. There are a large number of predefined categories (such as "syntax" etc) which map to known, fixed indexes within that string. However it is possible for modules to register custom warning categories (indeed, the "constant" and "overload" warning categories are custom, registered during "use constant" or "use overload"). Deparse, as originally written, masked out any custom categories when deciding whether the warnings state had changed (and thus a 'no/use warnings "foo"' needed emitting). This made the code easier as it didn't have to cope with variable-length bitmasks. However, after v5.27.5-387-g006c1a1dbd (which tried to handle the problem of unused bits in the last byte of the bitmask), then depending on how many pre-defined warning categories there were, as a side effect caused Deparse to start handling anywhere between 0 and 3 custom warning categories, depending on how many built-in categories there were in the current release. It just so happens that in the forthcoming release (5.36), the number of built-in categories is a multiple of 4, causing Deparse to handle 0 custom categories. Which is causing some 't/TEST -deparse' tests to fail. To fix this, this commit goes the full way and makes Deparse honour *all* custom warnings categories, both by removing the masking, and by normalising bitmask lengths before comparing them. Commit: 3b90549cbb135092c637895c2277a93c609640ec https://github.com/Perl/perl5/commit/3b90549cbb135092c637895c2277a93c609640ec Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M lib/B/Deparse.pm M lib/B/Deparse.t Log Message: ----------- Deparse: preserve booleanness of bool const values and general fixups to special constant values. Expressions like '$x = !0' were deparsed as '$x = 1'. Make it deparse as '$x = !0' instead. (!1 was already correctly handled.) This is important now that perl tries to preserve the "booleanness" of values; i.e. after $x = !0, $x is now marked as being boolean rather than just the int value 1. Formerly, Deparse handled the following special SVs: var output ----------- ------ PL_sv_undef 'undef' PL_sv_yes '1' PL_sv_no '!1' and any other unrecognised special SVs were incorrectly output as its index into into B's special SV table. These are now output as '???'. The recognised values are now: var output ----------- ------ PL_sv_undef 'undef' PL_sv_yes '!0' PL_sv_no '!1' PL_sv_zero '0' Note that PL_sv_zero was an oversight, now added, since I added that variable a few years ago. In practice it hasn't mattered, since there isn't currently (as far as I'm aware) any constant expression that could get constant folded to PL_sv_zero. Commit: 55d95e1b172db3fff30c261b7b7ea9e0bca8328a https://github.com/Perl/perl5/commit/55d95e1b172db3fff30c261b7b7ea9e0bca8328a Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M lib/B/Deparse.pm Log Message: ----------- Deparse: skip builtin state subs This line use builtin qw(foo bar); has the compile-time effect of state sub foo { ... } state sub bar { ... } (except that the subs are actually aliases of &builtin::foo and ::bar). Previously Deparse would output both the 'use builtin' line *and* the state sub definitions. This commit suppresses the outputting of state subs if they're in the package builtin::. Commit: f8245cd9653db9b3e3fef57c3913d9deb33972b2 https://github.com/Perl/perl5/commit/f8245cd9653db9b3e3fef57c3913d9deb33972b2 Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M ext/B/t/optree_for.t M lib/B/Deparse.pm M op.c M perly.act M perly.h M perly.tab M perly.y Log Message: ----------- for my ($x) ...: fix handling of degenerate 1-var The new for my ($x,$y,...) (...) { ... } syntax has a couple of problems in the degenerate case of a single variable: for my ($x) (...) { ... } First, the loop variable is marked as lexical, but not as a variable to be introduced. So it behaves roughly as if written like: { my $x; for $x (...) { ... } } I can't think of any user-visible runtime change in behaviour this bug causes, so I haven't included a test for it. Second, it was being incorrectly deparsed as for $x (...) { ... } (i.e. without the 'my'). This commit fixes both of these issues. The basic problem is that the parser, in the case of multiple vars, passes a list subtree of PADSVs as the 'sv' argument of Perl_newFOROP, but in the case of a single var, passes a single PADSV op instead. This single PADSV doesn't have the LVINTRO flag set, so is indistinguishable from plain my $x; for $x .... This commit makes the parser set the OPf_PARENS flag on the lone PADSV to signal to newFOROP() that it's a degenerate 1-var list, and newFOROP() sets the OPf_PARENS flag on the ENTERITER op to signal to the deparser that this is "for my (...)" syntax, even if it only has a single var. Commit: be68be95ee26f40ab8532e2b9f14997497f25f34 https://github.com/Perl/perl5/commit/be68be95ee26f40ab8532e2b9f14997497f25f34 Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M lib/B/Deparse.pm M lib/B/Deparse.t Log Message: ----------- Deparse: keep integer-valued nums as nums Previously, this: (-2.0, -1.0, -0.0, 0.0, 1.0, 2.0) deparsed as: (-2, -1, -.0, 0, 1, 2); now it deparses as-is, i.e. as: (-2.0, -1.0, -0.0, 0.0, 1.0, 2.0) This fixes 'cd t; ./TEST -deparse' failures in the new t/op/svflags.t file, which is very much concerned with the recent changes to preserve the original type of value assigned to a variable. Commit: 06d03a5dab926c7004a0bd61a79a8304f9946404 https://github.com/Perl/perl5/commit/06d03a5dab926c7004a0bd61a79a8304f9946404 Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M dist/threads/t/stack.t Log Message: ----------- threads: stack.t: make Deparse-friendly On non-threaded builds, it quits in the first BEGIN block because threads aren't enabled. This leaves an incomplete parse tree and thus heavily stunted Deparse output - in particular the vars declared before the BEGIN block are missing. By moving the var declarations/initialisation to after the first BEGIN block, it makes it compile again. Commit: df149086dad9dc6360487d020a6732784bae43e5 https://github.com/Perl/perl5/commit/df149086dad9dc6360487d020a6732784bae43e5 Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M Porting/deparse-skips.txt Log Message: ----------- update Porting/deparse-skips.txt ext/B/t/optree_for.t is a new test script which gets upset when for (...) {} gets deparsed as for (...) { (); } which produces a subtly different optree. So mark it as known failing for now. t/op/not.t was a skip, but seems to have been succeeding for while, so remove it from the skips file. Commit: b507a2212fa68b0ef9c8d18f6456b2f342acfc8f https://github.com/Perl/perl5/commit/b507a2212fa68b0ef9c8d18f6456b2f342acfc8f Author: David Mitchell <da...@iabyn.com> Date: 2022-04-16 (Sat, 16 Apr 2022) Changed paths: M Porting/deparse-skips.txt M dist/threads/t/stack.t M ext/B/t/optree_for.t M lib/B/Deparse.pm M lib/B/Deparse.t M op.c M perly.act M perly.h M perly.tab M perly.y Log Message: ----------- [MERGE] annual Deparse fixups There is a facility, "cd t; ./TEST -deparse", which feeds every test file through the deparser before running it. This is a good way of stress-testing the deparser. About once per year, I try to remember to run this, then try to fix all the accumulated bitrot acquired in the preceding year. This merge is my current attempt. With these fixes (plus updates to Porting/deparse-skips.txt), all tests now pass. The main changes are: * The new multi-var "for my ($x,$y,...) ..." syntax wasn't handling the degenerate case of a single var well. The optree it built wasn't quite right (although harmless, practically), but that screwed up deparsing, which was missing the 'my' on the output. * The new 'use builtin qw(foo bar)' was causing 'state sub foo {..}' etc to be emitted too. * As part of the drive to preserve the original type of a variable as far as possible, !0 is now deparsed as '!0' rather than as '1' to preserve its bool-ness, and integer-valued nums are now output as nums rather than integers, so 2.0 is now deparsed as '2.0' rather than '2'. * Appropriate "use/no warnings" lines are now emitted when the state of active warnings changes with respect to a custom warnings category. Historically these were ignored, then for the last few releases the first few custom categories were processed; now all new categories are registered. "The first few" was in fact anything from 0 to 3, depending on the number of builtin warning categories, modulo 4. It so happens that the current release gave an N%4 of 0, so no custom categories were being deparsed. Compare: https://github.com/Perl/perl5/compare/f5469426bb7b...b507a2212fa6