Front page | perl.perl5.porters |
Postings from December 2021
On Tue, 7 Dec 2021 09:59:28 +0000
Dave Mitchell <davem@iabyn.com> wrote:
> TL;DR: we need to agree what minimal changes we need for 5.36.0 to
> allow it to move out of experimental mode (not necessarily moving out
> in 5.36.0, but setting the foundations for moving it out in 2
> releases time).
I've been working on something similar to this. Branch is in
https://github.com/leonerd/perl5/commits/no-snails
(though I'm regularly rebasing + force-pushing so I won't link to
individual commits as they may move)
> My original proposals can be found in the thread
>
> Jumbo Signatures extensions discussion
> http://nntp.perl.org/group/perl.perl5.porters/256677
>
> and more specifically in the subthreads:
>
> @_ Suppression
> http://nntp.perl.org/group/perl.perl5.porters/256681
>
> Query Parameters
> http://nntp.perl.org/group/perl.perl5.porters/256680
>
> But it boils down to:
>
> 1) subs compiled within the scope of 'use signatures' don't get @_
> populated: @ is still the @_ of the caller. There is no separate
> pragma or other switch to allow this to be dis/enabled on a per-sub
> basis: if it's a signature sub, it doesn't get @_, full stop.
> Otherwise we'd have to have two code paths, two sets of tests etc for
> everything.
So far I have added a flag for this:
0356f47c3b Define a CvSIGNATURE flag
58603027bc Set the CvSIGNATURE flag on signatured subs
which allows pp_entersub to distinguish this situation.
> 2) Within the lexical scope of a signature sub (but not in the scope
> of e.g. nested signature-less anon subs etc), use of @_ and $_[X] is a
> compile-time warning. This should catch most coder errors associated
> with converting existing subs to use signatures.
Currently my code makes any access of @_ into a runtime error, purely
because that was somewhat easier to write than trying to make it
compiletime. It's enough to give a test of what things we have lurking
in core itself that would need updating, though yes a real release
wants it to be compiletime.
Mine is currently done with a new kind of magic applied to
GvAV(PL_defgv) within a signatured sub, that complains about any kind
of access on it.
809465cb35 Define a new type of variable magic, which prints an error
that access to a named variable is entirely forbidden
5eb1f7b999 Extend av_fetch() to check for PERL_MAGIC_forbidden on AVs
fc21e9e91e Apply PERL_MAGIC_forbid to @_ when running a signatured sub
...
> 4) In terms of implementation, the only logic that should go in
> pp_entersub() is checking a flag on the CV to see if it's a signatured
> sub. If so, it uses a pre-existing code path - the '&foo;' call
> mechanism. All the other logic should go in the sub itself -
> initially just as extra code in the OP_ARG* ops; later additions will
> add extra ops, and sometime after the sig implementation is complete,
> the optimiser will convert a suitable series of OP_ARG* ops into a
> single OP_SIGNATURE op which processes all args.
I altered the OP_ARG* code to pull the arguments out of the AV in pad
index 0:
8f767a2202 Get the pp_arg* funcs to look in PAD_SVl(0) instead of
GvAV(PL_defgv) for the args AV
Which seemed sufficient to at least allow them to continue to work,
while access to @_ was forbidden. That won't work for the longterm,
because in the longterm we (probably?) won't be putting the argument
values into the pad slot 0 AV either. But that's more of an internal
optimisation and shouldn't be user-visible so I wanted to focus on the
"ban @_" part first.
Overall, besides the first two commits that created CvSIGNATURE, plus
various fixes to tests/other files that were still using snail inside
signatured subs, I'm not particularly fond of the rest of what I made.
It was just a test to get this far and fix things like mktables. See
https://github.com/Perl/perl5/commit/70657aee92d84a1cd5a50bd81dfab71001372aad
> If agreement is reached, I'm likely to have enough
> enthusiasm to do the implementation work.
Yes; for the overall direction it would be good to find a good next set
of steps, and see about implementing those. In the meantime, I'm happy
to continue to use my current hack as a spyglass to find other code in
the core dist that would suffer "collateral damage" from a no-snails
change. We can (and should) just fix those up anyway, regardless of any
actual behavioural change to signatures for real.
I guess a "next step" would be to more precisely pin down what
behaviour we expect to see out of @_ within signatured subs, perhaps
by writing some more test cases in the style of t/op/signature.t so we
can agree on how it should behave.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next