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

Reply via email to