Nicholas Clark <nick@ccl4.org> wrote:
:> Looking closer at change
:> http://perl5.git.perl.org/perl.git/commitdiff/c427f4d2d4575fbc8a5190932fe321136c7597b3,
:> I think that is should be reverted from 5.10.1. This change makes
:> fold_constants assert in run-time when function used by public API.
:>
:> It's questionable that someone wants constant folding when he builds a
:> tree in run-time, but anyway it's better to fallback instead of
:> introducing more issues by earlier return, but there are could be
:> other functions that started to be foldable after that change.
:
:Given this:
:
:#define IN_PERL_COMPILETIME (PL_curcop == &PL_compiling)
:#define IN_PERL_RUNTIME (PL_curcop != &PL_compiling)
:
:and their widespread use:
:
:gv.c: else if (IN_PERL_COMPILETIME) {
:op.c: if (IN_PERL_RUNTIME) {
:perl.h: (IN_PERL_COMPILETIME ? IN_LOCALE_COMPILETIME : IN_LOCALE_RUNTIME)
:pp_ctl.c: if (IN_PERL_COMPILETIME) {
:pp_ctl.c: runtime = IN_PERL_RUNTIME;
:pp_ctl.c: PUSHBLOCK(cx, CXt_EVAL|(IN_PERL_COMPILETIME ? 0 : CXp_REAL), SP);
:pp_ctl.c: if (IN_PERL_COMPILETIME)
:regcomp.c: && IN_PERL_RUNTIME)
:regcomp.c: if (IN_PERL_COMPILETIME)
:sv.c: else if (IN_PERL_RUNTIME)
:sv.c: else if (IN_PERL_RUNTIME)
:sv.c: && IN_PERL_RUNTIME
:sv.c: if (IN_PERL_COMPILETIME) {
:sv.c: if (IN_PERL_RUNTIME)
:sv.c: if (IN_PERL_RUNTIME)
:utf8.c: if (IN_PERL_COMPILETIME) {
:utf8.c: if (IN_PERL_COMPILETIME)
:
:
:I don't believe that it's actually *legal* to build ops at runtime.
:Specifically, code that wants to build ops should "switch to compile time"
:for the duration of op-building, and switch back once finished.
:Otherwise the behaviour of the internals isn't going to be correct.
:
:I'm not sure what is involved in "switch to compile time". It may be as simple
:as re-pointing PL_curcop at PL_compiling, and ensuring that PL_compiling has
:the appropriate dynamic hints flags set I've not checked, but I assume that
:the code for the eval op shows the way to go on this. (And quite possibly,
:might have code that should be refactored out into a new piece of the API)
Hmm, I wonder if the regexp evals are doing the wrong thing here, and
creating some of the well known problems as a result. I do think I remember
tracing some of them down to either or both of PL_{curcop,compiling}.
Hugo
Thread Previous
|
Thread Next