ExtUtils::ParseXS after 5.52 prevents some XS modules to build

[book]

Recent versions of ExtUtils::ParseXS prevent older CPAN distributions to build.

Thrift-XS

See https://fast2-matrix.cpantesters.org/?dist=Thrift-XS+1.04 for reports.

The recent UNKNOWN all fail with Unparseable XSUB parameter.

• Example with Perl 5.41.13
• This report shows the same error with an older Perl (5.40.2), but a recent version of ExtUtils::ParseXS (3.57).

A DarkPAN module

At work, we have a module with the following xsp/typemap.xspt file (and several .xsp files (I think it's C++):

// Enable default XS typemaps
%loadplugin{feature::default_xs_typemap};

%typemap{double*}{simple};
%typemap{uint8_t}{simple};
%typemap{uint8_t*}{simple};
%typemap{int32_t}{simple};
%typemap{uint32_t}{simple};
%typemap{int64_t}{simple};
%typemap{uint64_t}{simple};
%typemap{SV*}{simple};
%typemap{AV*}{simple};
%typemap{HV*}{simple};
%typemap{std::string}{simple};
%typemap{std::unordered_set<std::string>&}{simple};
%typemap{std::vector<double>&}{simple};
%typemap{std::vector<uint64_t>&}{simple};
%typemap{ObjectType}{simple};

I've tried to build the distribution, with the same results for Perl 5.36.0 and 5.42.0,
with all version of ExtUtils-ParseXS between 3.51 and 3.61 (included):

• the dist built correctly with 3.51 and 3.52
• the dist failed to build with 5.53, warning about $} being undefined (which was fixed in 1744f58)
• the dist failed to build with all versions from 3.54 up to 3.61, and the following diagnostics stood out:

Could not find a typemap for C type 'std::unordered_set<std::string>&'.
Could not find a typemap for C type 'std::vector<double>&'.
Could not find a typemap for C type 'std::vector<uint64_t>&'.

[jkeenan]

Recent versions of ExtUtils::ParseXS prevent older CPAN distributions to build.

Thrift-XS

See https://fast2-matrix.cpantesters.org/?dist=Thrift-XS+1.04 for reports.

The recent UNKNOWN all fail with Unparseable XSUB parameter.

* [Example with Perl 5.41.13](https://www.cpantesters.org/cpan/report/5107b4b0-55ff-11f0-bc6d-4a456e8775ea)

* [This report](https://www.cpantesters.org/cpan/report/4d0d2b42-55ff-11f0-bc6d-4a456e8775ea) shows the same error with an older Perl (5.40.2), but a recent version of ExtUtils::ParseXS (3.57).

This was also reported upstream last June by Slaven: https://rt.cpan.org/Ticket/Display.html?id=167904; no response yet from distro author.

[book]

This was also reported upstream last June by Slaven: https://rt.cpan.org/Ticket/Display.html?id=167904; no response yet from distro author.

Sorry, my message wasn't clear: I managed to build Thrift-XS using ExtUtils-ParseXS 3.51.

[jkeenan]

Recent versions of ExtUtils::ParseXS prevent older CPAN distributions to build.

Thrift-XS

See https://fast2-matrix.cpantesters.org/?dist=Thrift-XS+1.04 for reports.

The recent UNKNOWN all fail with Unparseable XSUB parameter.

* [Example with Perl 5.41.13](https://www.cpantesters.org/cpan/report/5107b4b0-55ff-11f0-bc6d-4a456e8775ea)

* [This report](https://www.cpantesters.org/cpan/report/4d0d2b42-55ff-11f0-bc6d-4a456e8775ea) shows the same error with an older Perl (5.40.2), but a recent version of ExtUtils::ParseXS (3.57).

Treating the Thrift-XS part of the OP report as a BBC, I ran the following on unthreaded builds on Linux:

perl Porting/bisect.pl \
--module=Thrift::XS \
--start=87deea969a7552a96b077acb5708d74c65099c51 \
--end=v5.41.13

That pointed to a399a49 (v5.41.4-64-ga399a4923c) as the first breaking commit:

commit a399a4923c7f15aa1aa5bdb38a5dccf59ef51678
Author:     David Mitchell <davem@iabyn.nospamdeletethisbit.com>
AuthorDate: Mon Sep 23 18:52:11 2024 +0100
Commit:     David Mitchell <davem@iabyn.nospamdeletethisbit.com>
CommitDate: Fri Oct 18 11:12:17 2024 +0100

    ParseXS: refactor: XSUB signature-processing
    
    The previous commit reduced the three separate XSUB signature-splitting
    and initial processing branches into two. This commit reduces it to a
    single common block of code. It also heavily refactors the initial
    parameter processing code, and adds several new checks.
...

At this commit ExtUtils-ParseXS was at version 3.55.

@iabyn, can you take a look? Thanks.

[Leont]

• the dist failed to build with all versions from 3.54 up to 3.61, and the following diagnostics stood out:

Could not find a typemap for C type 'std::unordered_set<std::string>&'.
Could not find a typemap for C type 'std::vector<double>&'.
Could not find a typemap for C type 'std::vector<uint64_t>&'.

That's sounding like there's a regression in the typename normalization code. Probably involving characters that are valid in C++ typenames but not in C typenames (in this case :<>&)

[iabyn]

On Thu, Jan 22, 2026 at 06:21:54AM -0800, Philippe Bruhat (BooK) wrote: # Thrift-XS

This module has XSUBs signatures like void writeFieldBegin(TBinaryProtocol *p, SV * /*name*/, int type, int id) and one of the parameters is SV * /*name*/ which was never legal XS. Previously the XS parser quietly skipped any parameter which it couldn't parse. Which was insane. But one side effect of this was that any old unparseable garbage ended up acting as a placeholder parameter declaration, since the parser just skipped it. That particular example is unparseable because a) it doesn't have a parameter name, just a type; b) C comments aren't part of XS syntax When I made ParseXS start to complain about unparseable parameters, I added support for having a plain 'SV*' treated specially as a placeholder declaration, since that was quite a common idiom. I'm reluctant to add yet more special-case handling.

# A DarkPAN module At $work, we have a module with the following `xsp/typemap.xspt` file (and several `.xsp` files (I think it's C++): ``` // Enable default XS typemaps %loadplugin{feature::default_xs_typemap}; %typemap{double*}{simple}; %typemap{uint8_t}{simple}; %typemap{uint8_t*}{simple}; %typemap{int32_t}{simple}; %typemap{uint32_t}{simple}; %typemap{int64_t}{simple}; %typemap{uint64_t}{simple}; %typemap{SV*}{simple}; %typemap{AV*}{simple}; %typemap{HV*}{simple}; %typemap{std::string}{simple}; %typemap{std::unordered_set<std::string>&}{simple}; %typemap{std::vector<double>&}{simple}; %typemap{std::vector<uint64_t>&}{simple}; %typemap{ObjectType}{simple};

I have no idea what that syntax is, but it isn't XS. Presumably something is translating that into XS. Do you have the actual XS content which ParseXS is then choking on?

[haarg]

The xsp and xspt files are being processed by ExtUtils::XSpp.