Branch: refs/heads/davem/xs_refactor4
  Home:   https://github.com/Perl/perl5
  Commit: 4824221fe0d66db4bbea3f6891e76620f35d8cda
      
https://github.com/Perl/perl5/commit/4824221fe0d66db4bbea3f6891e76620f35d8cda
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: generate_output(): tweak code

Use a var called $retvar rather than a var called $sv and repeatedly
using "RETVAL$sv".


  Commit: 4cfea606e74b3656c900aa08f6871079b0fe5ddf
      
https://github.com/Perl/perl5/commit/4cfea606e74b3656c900aa08f6871079b0fe5ddf
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pod
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: process_file(): allow string ref filename

If the passed input 'filename' option is a reference, treat it
as a 'string' input file, i.e. open it with:

    open my $fh, '<', \$string

This allows test files to include short XS file texts as heredocs rather
than needing a separate t/TestFoo.xs test file.


  Commit: e3c60a9ae8b763e300662ceef6979a5d5c606258
      
https://github.com/Perl/perl5/commit/e3c60a9ae8b763e300662ceef6979a5d5c606258
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: 001-basic.t: rename Foo package

This test file includes a small package called Foo to create a tied
file handle to capture parse output.

Rename the package from 'Foo' to 'Capture' to better reflect its
purpose, and move its methods from the end of the test file to near the
beginning.


  Commit: 3aa963d91391a4197e2d1537afcc755358dc6275
      
https://github.com/Perl/perl5/commit/3aa963d91391a4197e2d1537afcc755358dc6275
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: add basic tests for =+; INPUT modifiers

XS supports the little-known input line modifiers:

    INPUT:
        int a = ($type)MySvIV($arg);
        int b ; blah($var);
        int c + blurg($var);

They are almost completely untested and unused in core. This commit adds
some basic tests for them, including how an embeded double-quote is
handled.


  Commit: 41fd6690e26ad9ccff65a3cedbf9f66af23b2393
      
https://github.com/Perl/perl5/commit/41fd6690e26ad9ccff65a3cedbf9f66af23b2393
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: use eval \a for for =+; INPUT modifiers

For the little-known input line modifiers:

    INPUT:
        int a = ($type)MySvIV($arg);
        int b ; blah($var);
        int c + blurg($var);

change how the variable-expansion quoting is handled.

OUTPUT has always used the \a (alert control char) double-quotish
delimiter (i.e.  q\a.....\a ) when passing a template read in from a
typemap file through eval. This avoids problems when the typemap
entry itself includes double-quote characters.

Commit v5.41.0-83-g2f4409bf70 made INPUT typemap entries also use \a.
(For some reason it had always used plain '"' up until then.)

This commit makes the evalling also use \a for typmap and other code
expressions extracted from the optional init part of an INPUT line.

Prior to this commit, the init string was first passed though a quote
escape, s/"/\\"/g, before then being passed to eval using ordinary
double quotes. This was sufficient when the typemap contained ("), but
not when it contained (\"), e.g.

        int c + foo("abc\"def");

So this commit makes it technically more accurate. It also makes the
code more consistent, which will help in some refactoring which will
follow.


  Commit: 131c77d9b524bde8f78c64ff1bc9d2baccf22dd3
      
https://github.com/Perl/perl5/commit/131c77d9b524bde8f78c64ff1bc9d2baccf22dd3
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: avoid evalling var name

In various places ParseXS passes a string (usually containing a
typemap entry) through eval, in order to expand, e.g.:

    ($type)SvIV($var)
into
    (int)SvIV(foo)

However, in some places it used eval just to expand the variable name,
i.e. it does the equivalent of:

    $expanded_name = eval q("$var");

which is effectively a no-op, since variable names (as extracted from
XSUB signatures, INPUT lines etc) will already have been restricted to
something like /\w+/ and so don't contain anything funky which could be
expanded by the eval.

Remove these evals in the interests of code clarify and security. (There
doesn't appear to be anything insecure at the moment, but it's always
best to avoid unnecessary evals.)


  Commit: 487390eae8f7fcbaeac63885a14729aa188ccc46
      
https://github.com/Perl/perl5/commit/487390eae8f7fcbaeac63885a14729aa188ccc46
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: more fully support function pointer types

This commit does two things: it finishes off adding support for function
pointer types, and it alters which part of ParseXS.pm is responsible for
printing out the variable name when emitting a C var declaration.

The function pointer fix is a by-product of changing how the var's name
is emitted. The change will also allow, in subsequent commits, for the
code to be cleaned-up and simplified. For now, it's just unconditionally
setting a variable called $printed_name to true,  and so all the
now-false branches in various places are now never taken.

In more detail.

INPUT typemaps tend to be in one of two forms:

    $var = ($type)SvFOO($arg)

and
    {
        ... big code block ...
        $var = ...;
    }

For the first, the typemap is used as-is to emit a combined declaration
and initialisation, e.g.

    int some_var = (int)SvFOO(ST(0));

while for the latter, the declaration and initialisation are split:

    int some_var;

    ....

    {
        ... big code  block ...
        some_var = ...;
    }

Before this commit, the caller of generate_init() or output_init() -
usually INPUT_handler() - was responsible for printing out the type
component of the variable declaration, while generate_init() was
responsible for emitting the variable name and any initialiser.

So for example, for the emitted line:

    int some_var = (int)SvFOO(ST(0));

INPUT_handler() would print "int", then the method generate_init(), via
expanding the typemap, would print " some_var = (int)SvFOO(ST(0));"

However, function pointer types are a bit of a problem, because in their
C declaration, the variable name is embedded *within* the type:

    int   my_int;          // var name to the right
    int (* my_fn_ptr)();   // var name embedded

Before this commit, ParseXS would convert a string containing a type
which matches '(*)' into a type including the variable name. So given
an XSUB variable declared as

    INPUT
        int (*)()   my_fn_ptr

then INPUT_handler(), when printing out the "type", would actually
print out "int (* my_fn_ptr)()", and set a flag, printed_name, when
calling generate_init(), to let it know that the variable name has
already been printed, and so doesn't need printing again.

generate_init(), when dealing with a long-form typemap, would
just print ";\n", then emit the big initialiser block later. However
for a short-form typemap it would panic, because it wants to just print
the expanded version of the '$var = ...' typemap, which would lead to
the variable name being printed twice, e.g.

    int (* my_fn_ptr)() my_fn_ptr = ....;

It is also makes the code in generate_init() messy, because it's
constantly doing 'if ($printed_name) { ... } else { ... }'.

This commit fixes the whole mess by the simple expedient of making the
caller always responsible for printing the var name in addition to the
type; so INPUT_handler() will now print out "int foo" rather than "int"
always.

We solve the problem of the typemap starting with '$var = ...' by the
simple expedient of deleting the leading '$var' substring from it before
expanding it.

Note that this commit causes some white-space changes in the C code
being generated: regardless of whether the INPUT typmap started with a
tab, the code now output is usually as if the typmap *did* start with a
tab.


  Commit: 78c465d55b7fcea90ffeb3171682ead76acbda33
      
https://github.com/Perl/perl5/commit/78c465d55b7fcea90ffeb3171682ead76acbda33
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: remove $printed_name and clean up

The previous commit made the $printed_name var and printed_name flag
always true. Now remove that flag and var and make all code which tested
it do the 'true' branch unconditionally.


  Commit: f302c09c4ccae67d41a7ae562e7f41050b39e562
      
https://github.com/Perl/perl5/commit/f302c09c4ccae67d41a7ae562e7f41050b39e562
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: rename xsub_map_argname_to_islength field

Rename

    $self->{xsub_map_argname_to_islength}
to
    $self->{xsub_map_argname_to_has_length}

A subtle difference: this hash is set when 'length(foo)' is seen in
signature, but it actually used when processing parameter 'foo' (rather
than parameter 'length(foo)'.


  Commit: 3ee3d1ffaed8b00d55951d499bc9b95bd69263f0
      
https://github.com/Perl/perl5/commit/3ee3d1ffaed8b00d55951d499bc9b95bd69263f0
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: minimise extent of typemap evals

Typemap INPUT and OUTPUT templates, e.g.

    $var = ($type)SvIv($arg)

are fed through an eval in double-quotish context to expand the template
variables. However, ParseXS.pm currently includes a whole bunch of other
string content in the evals. This is mostly harmless, but makes the code
confusing.

This commit pulls out all the extra string content to be outside the
eval, so that only the bare typemap template gets evaled.

For example this commit changes

    $self->eval_input_typemap_code(qq/print qq\a $init\\n\a/, $argsref);

to

    printf " %s\n",
      $self->eval_input_typemap_code("qq\a$init\a", $argsref);

so that now the 'print' isn't evalled,  and there's no need for \\n
etc.

Also, add a test that default values are still template-expanded.
I think this was an accident of implementation rather than being
intended, but it turns out that some distos (including Dynaloader) rely
upon that behaviour.

In theory there should be no visible change in behaviour.


  Commit: e33a97633ccd35fca8ef33747331bcf5ff5bd657
      
https://github.com/Perl/perl5/commit/e33a97633ccd35fca8ef33747331bcf5ff5bd657
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: generate_init(): add $default var

The expression

    $self->{xsub_map_argname_to_default}->{$var}

appears several times within generate_init(). Make the code easier on
the eye by assigning it to a lexical.


  Commit: 37506e650935d3b18569c57cb74e22e5d0653dcb
      
https://github.com/Perl/perl5/commit/37506e650935d3b18569c57cb74e22e5d0653dcb
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: add ST() method

Consolidate all the code which does $arg = "ST(" . ($num-1) . ")"
into one place, where edge-case handling can be centralised.


  Commit: 043899cbeb7186ee9057dff4cfd9f15d16b4db67
      
https://github.com/Perl/perl5/commit/043899cbeb7186ee9057dff4cfd9f15d16b4db67
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: eliminate output_init() method

This method is only used in one place, so delete it and instead
inline it in the caller. This will also help with future code
refactoring.

It's a private method, so in theory this commit should make no
difference functionally.


  Commit: a869fa9a4cee82ffef16eb398c5f5187d2f5631c
      
https://github.com/Perl/perl5/commit/a869fa9a4cee82ffef16eb398c5f5187d2f5631c
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: add tests for 'alien' INPUT parameters

Add tests for 'alien' INPUT parameters: ones which are declared in an
INPUT section but don't appear in the XSUB's signature. This aught to be
a compile error, but people rely on it to declare and initialise
variables which aught to be in a PREINIT or CODE section.

Also update a code comment which I got wrong earlier.


  Commit: 7382f612a7c05eaace52dc86bd3193ca8b626a1a
      
https://github.com/Perl/perl5/commit/7382f612a7c05eaace52dc86bd3193ca8b626a1a
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: generate_init(): eval in one place only

Recent refactoring has made it so that the various places in
generate_init() which eval a typemap template are all more or less the
same now.

So only have the call to eval_input_typemap_code() in a single
place.

Handle slight variants in the value of $expr being evalled by modifying
the result of the eval rather than modifying expr before. This is
slightly messier, but should provide the same functionality, and will
enable further refactoring.


  Commit: 465df40dee78b479a9cc0ffe97c656336a0ebe24
      
https://github.com/Perl/perl5/commit/465df40dee78b479a9cc0ffe97c656336a0ebe24
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: generate_init(): reorganise scope

Add a new { } scope around the chunk of perl code in generate_init()
which is directly responsible for generating C initialiser code from the
var's type via a typemap lookup.

In a follow-up commit, this block of code will shortly become one branch
of an if-else which will also handle also the case of the initialiser being
supplied rather than being looked up in a typemap.

This commit also shuffles around the locations of various 'my'
declarations to be in more suitable positions either in or outside the
new block, and divides the initialisation of %eval_vars into two halves.

The is no change in functionality, apart from the error message
"Error: No INPUT definition for type '$type'", which now includes the
actual type name (e.g. Foo::Bar) rather than the type munged by tr/:/_/.


  Commit: 3d09c3fdff44b7027715f3f2805048c30c15026d
      
https://github.com/Perl/perl5/commit/3d09c3fdff44b7027715f3f2805048c30c15026d
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: generate_init(): re-indent code block

The previous commit added a new { } scope. Now re-indent to match.

whitespace only.


  Commit: e8d55d37cf668b72bb69552f4f27d720277ad8d8
      
https://github.com/Perl/perl5/commit/e8d55d37cf668b72bb69552f4f27d720277ad8d8
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: generate_init(): add init parameter

Allow generate_init() to be called with an overridden initialiser
template which it will use instead of extracting one from a typemap.
Then use it in INPUT_handler().

This is part of a process to eventually do only parsing in
INPUT_handler() and do only code generation in generate_init().


  Commit: f088f47ec896e93ad9bc1d9583daf736578b447d
      
https://github.com/Perl/perl5/commit/f088f47ec896e93ad9bc1d9583daf736578b447d
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: generate_init(): add defer, no_init param

Allow generate_init() to be called with:

 - a no_init parameter, which disables initialiser generation:
     i.e. skip emitting '= SvIV(ST(0))' or whatever is derived from
     the typemap entry;

 - a defer parameter, which is template code which needs expanding and
    then emitted after all local variables have been declared.

Then use it in INPUT_handler().

Also add tests for XSUB parameters which have *both* default values and
initialisers. Make one of these tests TODO to preserve the current
behaviour, which is that for code like:

    int foo(a = 111)   // 111 is default value
      INPUT:
        int a = 222    // 222 is initialiser

the initialiser (222) is used, but no "if (items < 1) { a = 111 }"
is emitted. The changes in this commit actually fix this bug by default,
but I've added a temporary 'XXX' line of code which artificially disables
the fix - so that this commit makes no functional changes, and the fix
itself can addressed in a separate commit.

This commit is part of a process to eventually do *only* parsing in
INPUT_handler() and to do *only* code generation in generate_init().


  Commit: 1f5d4328e2e0213a7c6ac14a5533e989fa9bc5d1
      
https://github.com/Perl/perl5/commit/1f5d4328e2e0213a7c6ac14a5533e989fa9bc5d1
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: add tests for C++ THIS, CLASS params

If the XSUB name includes '::', the parser assumes that it's a C++
function being called and auto-adds a 'THIS' (or if new(), 'CLASS')
parameter.

Test that this actually happens.


  Commit: e4494f546424efafa4eea8b2063346a806c367e2
      
https://github.com/Perl/perl5/commit/e4494f546424efafa4eea8b2063346a806c367e2
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: make generate_init() emit type var decl

Before this commit, the *caller* of generate_init() was responsible for
emitting the type and var name part of a variable declaration and
initialisation, e.g. "char *s", while generate_init() emitted the rest,
e.g. "= (int)SvIV(ST(0));".

Following this commit, generate_init() is responsible for emitting the
*whole* declaration, including the type and var name.

This commit is a further part of a process to eventually do *only*
parsing in INPUT_handler() and to do *only* code generation in
generate_init().

But in particular, this commit makes it so that in some cases where
formerly INPUT_handler() just printed "type var;\n" and returned, it now
*always* calls generate_init() to do this (i.e. where before the call
was skipped).  This is a good thing in principle, because it means that
default values (handled by generate_init()) and overridden or skipped
initialisers (handled sometimes entirely by INPUT_handler()) are now
handled by the same function, and thus can be done correctly.

For example, various permutations along the lines of:

    int
    foo(a = 1, b = 2, c = NO_INIT)
        int a = my_int_converter($arg)
        int b = NO_INIT
        int c = my_int_converter($arg)

were getting completely screwed up: generally, the

    (if items >= N) { c = my_int_converter(ST(N)) }

wasn't getting emitted.

This commit actually keeps this broken behaviour for now:
it has a couple of 'XXX skip for now' conditions in generate_init(),
and adds a bunch of TODO tests. So in principle this commit
should have no visible change in behaviour. Later, we can decide
whether to fix these behaviours and risk breaking existing XS code.


  Commit: aa398367531770d2927eabfcf6a3440e636777b8
      
https://github.com/Perl/perl5/commit/aa398367531770d2927eabfcf6a3440e636777b8
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: disallow length() in INPUT section.

A length() pseudo-parameter, such as as

    int
    foo(char *s, int length(s))

is documented as being allowed only in ANSI-type function declarations.
In particular it means that this isn't legal:

    int
    foo(s)
        char *s
        int length(s)

The XS parser currently accepts that without complaint, but the
C code it generates is typically malformed: the wrapped C function is
called without a second length arg, and if the length() line comes after
the 'char *' line, the length var will not be initialised.

This commit makes the XS parser treat it as a parsing error,


  Commit: fa41ac0475221013277a1f9af5001721467a9961
      
https://github.com/Perl/perl5/commit/fa41ac0475221013277a1f9af5001721467a9961
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/t/001-basic.t
    M dist/ExtUtils-ParseXS/t/XSNoMap.xs

  Log Message:
  -----------
  ParseXS: update death() test

A test (that was added a year ago) checks that the death()
error-reporting method works. It uses a particular syntax error for the
test. The behaviour of that particular error will be changed in the next
commit: it will call blurt() rather than death(), so death() will no
longer be being tested.

So this commit updates the test so that it uses a different type of
syntax error, which we know will still trigger death().


  Commit: 81b6d144f9f2a7e056db067852ead52cd3c6be7b
      
https://github.com/Perl/perl5/commit/81b6d144f9f2a7e056db067852ead52cd3c6be7b
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: remove extra typemap check

Originally, the time at which the INPUT part of the XS parser would look
up a var's C type and try to associate it with a typemap was at the
time the relevant C var declaration and initialisation line was being
emitted. If not found, this was raised as a soft error (blurt()), so
compilation could continue (but xsubpp would eventually exit(1)).

Then a second typemap lookup call was added, this time earlier,
during INPUT line processing. This was used to help determine the
prototype (if any) of that argument. That code checks whether a valid
typemap was found, and not, falls back to using '$' as the prototype.
The result of that first typemap lookup is then thrown away.

Then, for some reason I don't quite understand, v5.15.0-499-g5a784a6530
added:

      $self->death("Could not find a typemap for C type '$var_type'")
         if not $typemap;

to the prototype-determining code. This seems a bit redundant, as the
typemap lookup a bit further down will report the error anyway, and the
prototype code can already code with no typemap being found.

But that new typemap error check has two problems. First. It does
death() rather than blurt(), stopping any further parsing.

Second, it fails to spot an overridden typemap. The  three lines below
are all valid: they provide their own initialiser, or skip
initialisation completely, so there's no need for a typemap entry for
the unknown type:

    INPUT:
        UnknownType foo1 = NO_INIT
        UnknownType foo2 = bar();
        UnknownType foo3 = baz($arg);

The code was now reporting any of those three lines as an error.

Then v5.15.2-79-gdcd8b78a7d partially fixed it (by looking for an
initialiser containing '$arg' or 'ST('), so that the foo3 line is now
valid, but the foo1 and foo2 lines were still generating an error.
The foo2 line may not make much sense, but it's legal, and the NO_INIT
line style is documented.

This commit removes the extra typemap check altogether. This has the two
effects of making typemap errors back into blurt()s rather than
death()s, and of making all 'UnknownType foo = ...' style lines legal
again. It may have the downside of breaking again whatever the extra
typemap check was added for, if it turns out that it had a purpose.


  Commit: fe5f10b5e501ab978d86e1cb241d0f6a04a35f1c
      
https://github.com/Perl/perl5/commit/fe5f10b5e501ab978d86e1cb241d0f6a04a35f1c
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: INPUT_handler(): make a regex //x

Make the regex more readable.


  Commit: 2e613b469ddcccebdb425a2a4b9bd3a6dd815fd4
      
https://github.com/Perl/perl5/commit/2e613b469ddcccebdb425a2a4b9bd3a6dd815fd4
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: INPUT_handler(): process length() later

Swap the order of splitting an INPUT line into it's components,
and processing where the variable name is 'length(name)'.

Makes the code cleaner - especially the pattern matching.

The diff is a bit confusing: in reality this commit has just two changes:
- the length()-processing s/// and block of code has been moved to later
  and updated;
- the line-splitting regex has been updated to match 'length(name)' in
  addition to 'name'.


  Commit: 2757f607a012e670b2f4b3b394f4397086d471a7
      
https://github.com/Perl/perl5/commit/2757f607a012e670b2f4b3b394f4397086d471a7
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: INPUT_handler(): reorder some code blocks

Swap the order of some of the code blocks, so that the parsing code
(mainly regexes) comes first, and the checking and state updating comes
second. This is in preparation for the second part to be moved into a
separate function.

Should be no functional changes.


  Commit: e7edf1867ab640876000440986d02c9accf43053
      
https://github.com/Perl/perl5/commit/e7edf1867ab640876000440986d02c9accf43053
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: INPUT_handler(): create $param hash

Put some of this sub's lexical state into a hash. This will will make
the next commit easier, when a chunk of code is moved out into its own
function.

No functional changes.


  Commit: 269340a92d0f99204e4f9af517225d1000634238
      
https://github.com/Perl/perl5/commit/269340a92d0f99204e4f9af517225d1000634238
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: add param_check() method

This private new method takes over the per-parameter state-updating
and checking currently done in INPUT_handler(). This leaves the body of
INPUT_handler() concerned with just the *parsing* of INPUT lines.

This new method will also be used shortly for processing ANSI-style XSUB
signatures directly rather than faking up synthetic INPUT lines.


  Commit: 536053b274d0adc5f6d707d337207d0262e4ba60
      
https://github.com/Perl/perl5/commit/536053b274d0adc5f6d707d337207d0262e4ba60
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: simplify and test for dup arg handling.

ExtUtils::ParseXS had no tests for the

    Error: duplicate definition of argument 'foo'

error message.

This commit adds some tests, and also simplifies the duplicate-detecting
code. A redundant check was causing the error to be printed *twice* for
the same parameter in something like:

    void foo(int a)
        int a

Removing this redundancy also allows the removal of the now-unused
$self->{xsub_map_argname_to_seen_type} object field.


  Commit: a2dc3befe40ca30be9338d49e95e3d4d54fe7b5b
      
https://github.com/Perl/perl5/commit/a2dc3befe40ca30be9338d49e95e3d4d54fe7b5b
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/t/001-basic.t

  Log Message:
  -----------
  ParseXS: add basic tests for OUT parameter

Add tests for where the param is declared OUT and then the type is
specified either in the signature or on a separate INPUT line


  Commit: d1911893aa6d508cec26ea748014ea8a606a756c
      
https://github.com/Perl/perl5/commit/d1911893aa6d508cec26ea748014ea8a606a756c
  Author: David Mitchell <[email protected]>
  Date:   2024-09-07 (Sat, 07 Sep 2024)

  Changed paths:
    M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm

  Log Message:
  -----------
  ParseXS: don't use fake INPUT line for ANSI param

Initially, XSUBs were declared using a K&R-like syntax, where the
parameters' types were specified later in INPUT lines:

    int
    foo(x, y)
        int x
        int y

Then about 25 years ago, ANSI-style signatures were allowed:

    int
    foo(int x, int y)

but the implementation was *horrible*. Basically the signature parser
just injected a fake INPUT section later on into the src code input
stream, containing lines like 'int x' etc.

As well as being ugly, it made the code hard to understand, and caused
all sorts of potential problems, since some syntax was specific to
ANSI params, like '=foo' default values, while other syntax was specific
to INPUT lines, like '= typemap_override($arg)'.

And in particular, the pseudo-parameter 'length(foo)' made *everything*
more complicated.

The commits leading to this one have been gradually splitting parameter
processing code into separate parsing, checking and code-emitting
functions. We can now make use of this separation so that, instead of
the signature-parsing code pushing a series of strings like 'int x' into
an array, to be injected back into INPUT_handler() later, we can instead
push a series of hashes along the lines of

    { name => 'x', type => 'int, ...}

Then when this list of hashes is processed, it can pass the hash
directly to the checking and code-generating methods, bypassing
INPUT_handler() completely.


Compare: https://github.com/Perl/perl5/compare/4824221fe0d6%5E...d1911893aa6d

To unsubscribe from these emails, change your notification settings at 
https://github.com/Perl/perl5/settings/notifications

Reply via email to