Richard Leach 5eb6a00307 Add a test for GH #16943 assertion failure
The asserting fuzzed test case was:

    eval q!s,,$0[sub{m[]]],;s,,$0[sub{m[]]],}}!

The assertion triggered was:

    pad.c​:614​: Perl_pad_add_anon​: Assertion `!CvWEAKOUTSIDE((const CV *)sv)' failed.

This behaviour was long standing, present in v5.8.8 if not earlier, then
was addressed by:
```
commit eb54d46
Author: Yves Orton <demerphq@gmail.com>
Date:   Fri Aug 26 18:26:14 2022 +0200

    Stop parsing on first syntax error.

    We try to keep parsing after many types of errors, up to a (current)
    maximum of 10 errors. Continuing after a semantic error (like
    undeclared variables) can be helpful, for instance showing a set of
    common errors, but continuing after a syntax error isn't helpful
    most of the time as the internal state of the parser can get confused
    and is not reliably restored in between attempts. This can produce
    sometimes completely bizarre errors which just obscure the true error,
    and has resulted in security tickets being filed in the past.

    This patch makes the parser stop after the first syntax error, while
    preserving the current behavior for other errors. An error is considered
    a syntax error if the error message from our internals is the literal
    text "syntax error". This may not be a complete list of true syntax
    errors, we can iterate on that in the future.

    This fixes the segfaults reported in Issue #17397, and #16944 and
    likely fixes other "segfault due to compiler continuation after syntax
    error" bugs that we have on record, which has been a recurring issue
    over the years.
```
2026-01-24 23:01:10 +00:00
..
2025-09-02 18:20:20 -06:00
2025-09-02 18:20:20 -06:00
2025-09-17 10:41:39 +10:00

This is the perl test library.  To run the test suite, just type './TEST'
or 'make test' from the build directory above t/.  See also the section
"Special Make Test Targets" in pod/perlhack.pod to learn about other
specific test commands.

To add new tests, just look at the current tests and do likewise.
The library t/test.pl provides some utility functions that you can use
in most tests, except in the most basic ones.

If a test fails, run it by itself to see if it prints any informative
diagnostics.  If not, modify the test to print informative diagnostics.
If you put out extra lines with a '#' character on the front, you don't
have to worry about removing the extra print statements later since TEST
ignores lines beginning with '#'.

If you know that Perl is basically working but expect that some tests
will fail, you may want to use Test::Harness thusly:
        cd t
        ./perl harness
This method pinpoints failed tests automatically.

If you come up with new tests, please submit them to
https://github.com/Perl/perl5/issues.

Tests in the t/base/ directory must be runnable with plain miniperl alone.
That is, they should not assume that require works, let alone that they can
require Config.pm, strict or warnings.  This constraint is frustrating, but
necessary as they exist to sanity test the rest of the test framework.
TEST will abort if any tests in the t/base/ directory fail.

Tests in the t/comp/, t/cmd/, t/run/, t/io/, t/op/ and t/uni/ directories
should also be runnable by miniperl and not require Config.pm, but
failures to comply will not cause TEST to abort like for t/base/.

The comment in TEST explains the test bootstrapping order:

* base first, as TEST bails out if that can't run
* then comp, to validate that require works
* then run, to validate that -M works
* then we know we can -MTestInit for everything else, making life simpler

Tests in t/perf/ are designed to test performance and optimisations,
and also contain additional tools and files designed to run outside
of the test suite