B-C
view release on metacpan or search on metacpan
ramblings/5.22-problems.md view on Meta::CPAN
Fixed 5.22 problems during my compiler port
===========================================
I uncovered and fixed many 5.22 problems with
[cperl](http://perl11.org/cperl/) already, but in the last months I
was busy to port the 3 compilers B::C, B::CC and B::Bytecode to 5.22.
As I said in my [interview](http://perlhist.com/perl30/reini-urban)
it's my belief that if all current p5p core committers would stop
committing their bad code it would be actually be the best for the
perl5 project. They weren't able to implemented any of the already
properly designed features from perl6 in the last 12 years, and every
feature they did implement is just so horrifibly bad, making our
already bad code base, which led to reimplementation efforts of
perl6/parrot with a better core, even worse. With cperl I can only
undo a little, but when they start breaking the API and planned
features in an incompatible way they should just stop.
Nevertheless, 5.22 added a significant improvement from outside,
syber's monomorphic inline caching for method calls besides the
internal improvement of multideref by Dave Mitchell.
Now to the problems I had to fix in the last months with that 5.22.0 release:
1. Father broke ByteLoader
===========================
[cperl #75](https://github.com/perl11/cperl/issues/75)
[perl-compiler](https://github.com/rurban/perl-compiler/commit/3582cffaa26060b5763ae9c840736195bd10e694)
This is something I cannot fix in the compiler. I updated my perl patcher
`App::perlall` with new --patches=Compiler patches to fix this, and cperl of course
also has this fix.
I had to write a complicated
[probe mechanism](https://github.com/rurban/perl-compiler/commit/6dab39642f6444b8fde4cb3e66b7a7d81745babb)
for ByteLoader to check if the used perl5.22 version is already
patched or not. Probing a to-be-built XS submodule is not that easy. A
typical chicken and egg problem. I could use my already existing
B::C::Flags helper config, which allows custom compiler settings.
There I initialize the variable `$B::C::Flags::have_byteloader` with
undef, and when the XS modules are all built I call a helper script to
probe for a working ByteLoader, and patch
`$B::C::Flags::have_byteloader` to 0 or 1. I can use this then in the
tests to skip or run the bytecode tests. And I had to put this helper
script into the hints directory to skip it from being
installed. Messing with EUMM libscan() was too dirty for me.
The internal compiler op.c creates a new main or eval environment with
`newPROG()`, setting the entry points `PL_main_start` and `PL_main_root`
from the intermediate parsed `PL_compcv`. In the case of en empty source
the parser always adds a final `;` semicolon, which leads to an empty optree
starting with `OP_STUB`.
But with commit
[34b5495](http://perl5.git.perl.org/perl.git/commitdiff/34b54951568575920f2307bea918f5549bd5a82f)
for [perl #77452] the compiler now always adds a LINESEQ in front of
the STUB, but the logic in newPROG for source filters which already
setup `PL_main_start` and `PL_main_root` wasnot changed, which led to
a broken ByteLoader.
This is an interesting commit as it added a lot of wrong comments
about the inner working of this, but didn't update the logic.
The fix in cperl is
[here](https://github.com/perl11/cperl/commit/309dc8e9649acda055a86514ca334bdfea31c0f8)
( run in 1.649 second using v1.01-cache-2.11-cpan-8f98c5d2c55 )