| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This defines a new magic hash C<%{^HOOK}> which is intended to be used for
hooking keywords. It is similar to %SIG in that the values it contains
are validated on set, and it is not allowed to store something in
C<%{^HOOK}> that isn't supposed to be there. Hooks are expected to be
coderefs (people can use currying if they really want to put an object
in there, the API is deliberately simple.)
The C<%{^HOOK}> hash is documented to have keys of the form
"${keyword}__${phase}" where $phase is either "before" or "after"
and in this initial release two hooks are supported,
"require__before" and "require__after":
The C<require__before> hook is called before require is executed,
including any @INC hooks that might be fired. It is called with the path
of the file being required, just as would be stored in %INC. The hook
may alter the filename by writing to $_[0] and it may return a coderef
to be executed *after* the require has completed, otherwise the return
is ignored. This coderef is also called with the path of the file which
was required, and it will be called regardless as to whether the require
(or its dependencies) die during execution. This mechanism makes it
trivial and safe to share state between the initial hook and the coderef
it returns.
The C<require__after> hook is similar to the C<require__before> hook
however except that it is called after the require completes
(successfully or not), and its return is ignored always.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes the "last successful pattern" as a variable that can be
printed, or used in patterns, or tested for definedness, etc. Many regex
magical variables relate to PL_curpm, which contains the last successful
match. We never exposed the *pattern* directly, although it was
implicitly available via the "empty pattern". With this patch it is
exposed explicitly. This means that if someone embeds a pattern as a
match operator it can then be accessed after the fact much like a qr//
variable would be.
@ether asked if we had this, and I had to say "no", which was a shame as
obviously the code involved isn't very complicated (the docs from this
patch are far larger than the code involved!). At the very least
this can be useful for debugging and probably testing. It can also
be useful to test if the /is/ a "last successful pattern", by checking
if the var is defined.
|
| |
|
|
|
| |
You can't say $^ENCODING, you need to say ${^ENCODING}, so spell it
right in the comments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two functions do a slightly odd thing (which has been present
since 5.000) when calling out to a CV: they half fake up an OP_ENTERSUB,
then call pp_entersub() directly, and only then if it returns a non-null
PL_op value, execute the rest of the ops of the sub within a
CALLRUNOPS() loop.
I can't find any particular reason for this. I guess it might make
calling XS subs infinitesimally faster by not have to invoke the runops
loop when only a single op is executed (the entersub), but hardly seems
worth the effort.
Conversely, eliminating this special-case makes the code cleaner, and
it will allow the workarounds planned to be added shortly (to the runops
loops for reference-counted stacks) to work uniformly. Without this
commit, pp_entersub() would get called before runops() has had a chance
to fix up the stack if necessary.
So this commit *fully* populates the fake OP_ENTERSUB (including type
and pp address) then causes pp_entersub to be invoked implicitly from the
runops loop rather than explicitly.
|
| |
|
|
| |
it and break stuff
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new experimental warning, feature, keywords and enough parsing to
implement basic classes with an empty `new` constructor method.
Inject a $self lexical into method bodies; populate it with the object instance, suitably shifted
Creates a new OP_METHSTART opcode to perform method setup
Define an aux flag to remark which stashes are classes
Basic implementation of fields.
Basic anonymous methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GH 20435 many typos in our C code were corrected. However, this pull
request was not applied to blead and developed merge conflicts. I
extracted diffs for the individual modified files and applied them with
'git apply', excepting four files where patch conflicts were reported.
Those files were:
handy.h
locale.c
regcomp.c
toke.c
We can handle these in a subsequent commit. Also, had to run these two
programs to keep 'make test_porting' happy:
$ ./perl -Ilib regen/uconfig_h.pl
$ ./perl -Ilib regen/regcomp.pl regnodes.h
|
| |
|
|
|
|
|
|
|
| |
The api for amagic_find() didnt make as much as sense as we thought
at first. Most people will be using this as a predicate, and don't
care about the returned CV, so to simplify things until we can really
think this through the required API this switches it to return
a bool and renames it to amagic_applies(), as in "which amagic_applies
to this sv".
|
| |
|
|
|
|
|
| |
Returns the CV pointer to the overloaded method,
which will be needed by join to detect concat magic.
Co-authored-by: Philippe Bruhat (BooK) <book@cpan.org>
|
| |
|
|
|
|
|
|
|
| |
gcc 12 was complaining that evaluating (somehekptr)->hek_key
was always true in many places where HvNAME() or HvENAME() was
being called in boolean context.
Add new macros to check whether the names should be available and
use those instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a weird bifurcation of the cop logic around threads. With
threads we use a char * cop_file member, without it we use a GV * and
replace cop_file with cop_filegv.
The GV * code refcounts filenames and more or less efficiently shares
the filename amongst many opcodes. However under threads we were
simplify copying the filenames into each opcode. This is because in
theory opcodes created in one thread can be destroyed in another. I say
in theory because as far as I know the core code does not actually do
this. But we have tests that you can construct a perl, clone it, and
then destroy the original, and have the copy work just fine, this means
that opcodes constructed in the main thread will be destroyed in the
cloned thread. This in turn means that you can't put SV derived
structures into the op-tree under threads. Which is why we can not use
the GV * stategy under threads.
As such this code adds a new struct/type RCPV, which is a refcounted
string using shared memory. This is implemented in such a way that code
that previously used a char * can continue to do so, as the refcounting
data is located a specific offset before the char * pointer itself.
This also allows the len data to embedded "into" the PV, which allows
us to expose macros to acces the length of what is in theory a null
terminated string.
struct rcpv {
UV refcount;
STRLEN len;
char pv[1];
};
typedef struct rcpv RCPV;
The struct is sized appropriately on creation in rcpv_new() so that the
pv member contains the full string plus a null byte. It then returns a
pointer to the pv member of the struct. Thus the refcount and length and
embedded at a predictable offset in front of the char *, which means we
do not have to change any types for members using this.
We provide three operations: rcpv_new(), rcpv_copy() and rcpv_free(),
which roughly correspond with newSVpv(), SvREFCNT_inc(), SvREFCNT_dec(),
and a handful of macros as well. We also expose SAVERCPVFREE which is
similar to SAVEGENERICSV but operates on pv's constructed with
rcpv_new().
Currently I have not restricted use of this logic to threaded perls. We
simply do not use it in unthreaded perls, but I see no reason we
couldn't normalize the code to use this in both cases, except possibly
that actually the GV case is more efficient.
Note that rcpv_new() does NOT use a hash table to dedup strings. Two
calls to rcpv_new() with the same arguments will produce two distinct
pointers with their own refcount data.
Refcounting the cop_file data was Tony Cook's idea.
|
| | |
|
| |
|
|
| |
I overlooked this case when SVf_QUOTEDPREFIX was introduced
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
messages.
These new formats are intended to be used in error messages where
we want to show the contents of a string without any possible
hidden characters not rendering in the error message, and where
it would be unreasonable to show every character of the string
if it is very long.
A good example would be when we want to say that a class name is
illegal. Consider:
"Foo\0"->thing()
should not throw an error message about "Foo" being missing, the fact
there is a null in there should be visible to the developer.
Similarly if we had
("x" x 1000_000)->thing()
we also do not want to throw a 1MB error message as it is generally
just unhelpful, a class name that long is almost certainly a mistake.
Currently this patch restricts it to showing 256 characters, the first
128 followed by an ellipses followed by the last 128 characters, but the
docs are such that we can change that if we wish, I suspect something
like 100 would be more reasonable. You can override the define
PERL_QUOTEDPREFIX_LEN to a longer value in Configure if you wish.
Example usage:
other= newSVpvs("Some\0::Thing\n");
sv_catpvf(msg_sv,"%" SVf_QUOTEDPREFIX, SVfARG(other));
Should append
"Some\0::Thing\n"
to the msg_sv. If it were very long it would have ellipses infixed. The
class name "x" x 1_000_000 would show
Can't locate object method "non_existent_method" via \
package "x[repeated 128 times]"..."x[repeated 128 times]" \
(perhaps you forgot to load \
"x[repeated 128 times]"..."x[repeated 128 times]"?) at -e line 1.
(but obviously as one line with the literal text of the class instead of
"[repeated 128 times]")
This patch changes a variety of error messages that used to output the
full string always. I haven't changed every place that this could happen
yet, just the main ones related to method calls, subroutine names and
the like.
|
| |
|
|
| |
The new Perl_newSVhek_mortal function is slightly more efficient.
|
| |
|
|
| |
Also renames the CvMETHOD* macro family to CvNOWARN_AMBIGUOUS*
|
| | |
|
| |
|
|
| |
Fix some typos.
|
| |
|
|
|
| |
This was meant to be a part of the previous commit, but somehow got
omitted.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I believe the '!!' is somewhat obscure; I for one didn't know about it
for years of programming C, and it was buggy in one compiler, which is why
cBOOL was created, I believe. And it is graphically dense, and
generally harder to read than the cBOOL() construct.
This commit dates from before we moved to C99 where we can simply cast
to (bool), and cBOOL() has been rewritten to do that. But the vast
majority of code uses cBOOL(), and this commit brings the remainder of
the core .[ch] files into uniformity.
|
| |
|
|
| |
I read the code and added details previously missing.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
One should use the macro front end instead.
|
| | |
|
| |
|
|
|
| |
In practice, like in perlguts, GVs and Stashes are lumped together, and
some API functions deal with both. So rename the section they go in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no efficient way to create a mortal SV of any type other than
SVt_NULL (via sv_newmortal). The options are either to do:
* SV* sv = sv_newmortal; sv_upgrade(sv, SVt_SOMETYPE);
but sv_upgrade is needlessly inefficient on new SVs.
* SV* sv = sv_2mortal(newSV_type(SVt_SOMETYPE)
but this will perform runtime checks to see if (sv) and if (SvIMMORTAL(sv),
and for a new SV we know that those answers will always be yes and no.
This commit adds a new inline function which is basically a mortalizing
wrapper around the now-inlined newSV_type.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a function outside of sv.c creates a SV via newSV(0):
* There is a call to Perl_newSV
* A SV head is uprooted and its flags set
* A runtime check is made to effectively see if 0 > 0
* The new SV* is returned
Replacing newSV(0) with newSV_type(SVt_NULL) should be more efficient,
because (assuming there are SV heads to uproot), the only step is:
* A SV head is uprooted and its flags set
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a space optimisation, where possible, sub declarations are stored in the
symbol table as a plain scalar, and converted to a PVGV, PVCV pair only when
needed.
A regression was introduced by the recently merged commit bb5bc97fde9ef2f1:
Don't set SVf_POK in Perl_sv_2pv_flags() when caching the string for an IV.
This permits XS code (such as serialisers) to distinguish between values
that started as IVs but had a string representation cached, and values that
started as PVs but had an (exact) integer representation cached.
As implemented, the change in flags means that Perl_sv_2pv_flags() will be
entered each time the string for an IV is wanted. The next commit will fix
SvPV() and the other macros to avoid calling Perl_sv_2pv_flags() more than
once, restoring the previous behaviour.
Specifically, code which reduces to this:
sub foo;
$::{foo} . "";
eval q{*foo = []};
changed behaviour (to an assertion failure)
Previously the runtime behaviour of the middle line (simplifying slightly)
was to convert the IV -1 to the PVIV "-1". The third line would then see
this as a(n illegal) prototype "-1", but the code in Perl_gv_init_pvn()
would diligently move this across to the PVCV it created, and finish with a
structurally valid PVGV and PVCV
With the recent commit, the second line would still convert to PVIV, but no
longer set the flag bit SVf_POK. This meant that with this same test case,
the SvPOK() test in Perl_gv_init_pvn() was no longer true, and a different
code path was taken, resulting in broken assumptions and an assertion
failure (when assertions are enabled).
Fixing this regression also fixes a long standing bug, likely present since
the commit from 1998 that added this space optimisation. This pathological
code:
sub foo;
$::{foo} . "";
eval q{ sub foo {} };
use to incorrectly warn:
Prototype mismatch: sub main::foo (-1) vs none at (eval 1) line 1.
because the placeholder -1 for "no prototype" had been converted to a
string, that string then copied because it seemed to be a placeholder
prototype, and then the warning issued on the mistaken incorrect prototype.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On threaded builds CopFILEAV() calls gv_fetchfile(), which always
created the *{"::_<filenamehere"} glob, so the attempted clean up
here could recreate the glob, even if it has already been removed
when cleaning up a string eval.
To avoid this, add CopFILEAVn() that never creates the glob,
nor the AV so that the clean up never adds new objects.
This change makes the check for PL_phase unnecessary, but that check
is much cheaper than the call for gv_fetchfile_flags() that the
macro hides, so retain the check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typeglob assignment causes the current GP to be freed, and hence any package
variables it contains. As Perl's (data) stack is not reference counted, SVs
put on it are assumed to be owned by something else. For package variables,
this assumed owner is the typeglob. Hence if a single statement contains
both assignment to a typeglob and use of one of its variables, the
interpreter can read garbage (with all the usual explosive consequences).
This is yet another manifestation of "the stack is not reference counted",
and whilst troubling from a correctness perspective, can't be exploited
unless one can already run arbitrary code, in which case any attacker has
already won.
Whilst this problematic code doesn't turn up very often in real programs,
let alone hot paths, it is found quite often by researchers running
automated fuzzers. Previously these programs would trigger errors, that the
researchers would (legitimately) report, and then we would spend time
figuring out that the cause was "stack not reference counted" and so not a
dangerous security hole. This consumed a lot of researcher time, our time,
and prevents "interesting" security holes being uncovered.
Hence add code to use the temps stack to paper over the lack of stack
reference counting in this specific case. This should avoid a lot of time
spent on assessing and responding to legitimate but uninteresting security
reports, at a small cost in code complexity.
|
| |
|
|
|
| |
Per hv review in
https://github.com/Perl/perl5/pull/19132#issuecomment-920155495.
|
| |
|
|
|
|
|
| |
Two build-time warnings appeared when building with g++10 as compared
with g++9. Both were:
"suggest parentheses around assignment used as truth value"
|
| |
|
|
|
|
|
|
|
|
|
| |
These are identified as being static shared COW strings whose string
buffer points directly at PL_Yes / PL_No
Define sv_setbool() and sv_setbool_mg() macros
Use sv_setbool() where appropriate
Have sv_dump() annotate when an SV's PV buffer is one of the PL_(Yes|No) special booleans
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds syntax `defer { BLOCK }` to create a deferred block; code that is
deferred until the scope exits. This syntax is guarded by
use feature 'defer';
Adds a new opcode, `OP_PUSHDEFER`, which is a LOGOP whose `op_other` field
gives the start of an optree to be deferred until scope exit. That op
pointer will be stored on the save stack and invoked as part of scope
unwind.
Included is support for `B::Deparse` to deparse the optree back into
syntax.
|
| |
|
|
|
|
| |
Previously the flag bit was set and cleared for each iteration of the outer
loop. The compiler *might* have made this optimisation that this commit makes
for us, but might not.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
For the `isa` infix operator, we can fall back to `sv_derived_from_sv`
instead of looking up UNIVERSAL::isa. Passing GV_NOUNIVERSAL will tell
gv_fetchmeth_internal not to look at UNIVERSAL for the method, and instead
return NULL. Then `Perl_sv_isa_sv` will skip the if block and check
`sv_derived_from_sv` which does the same thing UNIVERSAL::isa would have done.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Add feature, experimental warning, keyword
* Basic parsing
* Basic implementation as optree fragment
See also
https://github.com/Perl/perl5/issues/18504
|
| |
|
|
|
|
|
|
|
|
|
| |
This just detabifies to get rid of the mixed tab/space indentation.
Applying consistent indentation and dealing with other tabs are another issue.
Done with `expand -i`.
* vutil.* left alone, it's part of version.
* Left regen managed files alone for now.
|
