| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It was planned to make certain changes in 5.18, but this didn't happen.
Change the expected version to 5.20, and add some detail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
6.66 Fri Apr 19 17:53:13 BST 2013
No changes from 6.65_03
6.65_03 Mon Apr 15 13:44:24 BST 2013
Test Fixes
* Use File::Temp in parse_* tests to resolve race conditions
on 64bit Windows
(bingos)
6.65_02 Sun Apr 14 10:56:41 BST 2013
Test Fixes
* t/xs.t is now running tests against the XS build.
(Michael G Schwern) (Leon Timmermans)
6.65_01 Tue Mar 19 00:06:17 CET 2013
New Features
* Improvements perlcritic support. (M. Schwern)
* Improvements to dynamic linking for gcc (Tobias Leich)
[github #43]
* Change $(PERL_HDRS) from a hard coded list of headers to
reading install directory for available header files. Allows
us to work with any version of Perl properly.
(Yves Orton, Craig A. Berry) [github #47]
Doc Fixes
* Numerous typo fixes. (Ben Bullock)
[github #33] [github #34] [github #35]
* Various FAQ and doc improvements (M. Schwern, Ivan Bessarabov)
[github #44]
Bug Fixes
* fixes relating to hash ordering (Yves Orton)
[github #46] [rt.cpan.org #83441] [rt.perl.org #116857]
* fixes to Mksymlists (Ben Bullock, Yves Orton)
[github #48] [github #49] [github #51]
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
same fix as in the last commit in cachepropagate-udp.t
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
|
| |
|
|
| |
https://rt.perl.org/rt3/Ticket/Display.html?id=117477
|
| | |
|
| |
|
|
|
|
| |
Transcoded README.{cn,jp,ko} to utf-8
Fixed encoding lines for README.{cn,jp,ko,tw}
Fixed verbatim text for README.{cn,ko}
|
| |
|
|
|
| |
Also document that this means that ranges and bigint.pm do not mix perfectly.
Bump version numbers.
|
| |
|
|
|
|
|
| |
Incorporate Nicholas Clark's suggestions.
Correct pod formatting errors.
For: RT #117003
|
| |
|
|
| |
For: RT #116479
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
2013-04-12 Andreas Koenig <k@UX31A>
* release 2.00 (at Lancester #QA2013)
* Removed the trial status for the release in the Makefile.PL
* Merge with App::Cpan 0.61 (just a version number change)
|
| |
|
|
|
|
|
| |
Documentation patch submitted by Brad Gilbert++ provoked discussion concerning
whether this program is still needed. Consensus was that it is not.
For: RT #117185
|
| | |
|
| |
|
|
| |
B::Deparse no longer emits the warnings in question.
|
| |
|
|
|
|
| |
This doesn't work properly, but (a) it's better than nothing, and (b) it
suppresses some unsightly "unexpected OP_INTROCV" warnings from the test
suite, fixing RT #116821.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reworking of the re_eval implementation for 5.17.1 made the assumption
that constant strings within literal patterns were, um, constant.
It turns out this this is an invalid assumption, because
overload::constant qr => { sub return bless [], 'Foo' }
can cause the constant bits of a pattern, like foo, bar in
/foo(?{...})bar/
to get replaced with (for example) blessed objects: so the 'constant' SV
attached to an OP_CONST is actually a blessed object, that could itself be
overloaded with string or concat methods say, or could be a qr// object
etc.
The commits in this merge (hopefully) fix the various problems this
assumption caused: chiefly with qr// objects containing compiled (?{})
code that were getting re-stringified and thus failing unless in the
presence of use re 'eval' (and sometimes failing even in its presence).
Also, runtime patterns could trigger a recursive call to the overload
method, and eventually stack overflow and SEGV.
See [perl #116823].
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are two issues fixed here.
First, when a pattern has a run-time code-block included, such as
$code = '(?{...})'
/foo$code/
the mechanism used to parse those run-time blocks: of feeding the
resultant pattern into a call to eval_sv() with the string
qr'foo(?{...})'
and then extracting out any resulting opcode trees from the returned
qr object -- suffered from the re-parsed qr'..' also being subject to
overload:constant qr processing, which could result in Bad Things
happening.
Since we now have the PL_parser->lex_re_reparsing flag in scope throughout
the parsing of the pattern, this is easy to detect and avoid.
The second issue is a mechanism to avoid recursion when getting false
positives in S_has_runtime_code() for code like '[(?{})]'.
For patterns like this, we would suspect that the pattern may have code
(even though it doesn't), so feed it into qr'...' and reparse, and
again it looks like runtime code, so feed it in, rinse and repeat.
The thing to stop recursion was when we saw a qr with a single OP_CONST
string, we assumed it couldn't have any run-time component, and thus no
run-time code blocks.
However, this broke qr/foo/ in the presence of overload::constant qr
overloading, which could convert foo into a string containing code blocks.
The fix for this is to change the recursion-avoidance mechanism (in a way
which also turns out to be simpler too). Basically, when we fake up a
qr'...' and eval it, we turn off any 'use re eval' in scope: its not
needed, since we know the .... will be a constant string without any
overloading. Then we use the lack of 'use re eval' in scope to
skip calling S_has_runtime_code() and just assume that the code has no
run-time patterns (if it has, then eventually the regex parser will
rightly complain about 'Eval-group not allowed at runtime').
This commit also adds some fairly comprehensive tests for this.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When re-parsing a pattern for run-time (?{}) code blocks,
we end up with the EVAL_RE_REPARSING flag set in PL_in_eval.
Currently we clear this flag as soon as scan_str() returns, to ensure that
it's not set if we happen to parse further patterns (e.g. within the
(?{ ... }) code itself.
However, a soon-to-be-applied bugfix requires us to know the reparsing
state beyond this point. To solve this, we add a new boolean flag to the
parser struct, which is set from PL_in_eval in S_sublex_push() (with the
old value being saved). This allows us to have the flag around for the
entire pattern string parsing phase, without it affecting nested pattern
compilation.
|
| | |
| |
| |
| |
| |
| | |
The previous commit added an alternative flag mechanism to
PL_reg_state.re_reparsing, but kept the old one around for consistency
checking. Remove the old one now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
PL_reg_state.re_reparsing is a hacky flag used to allow runtime
code blocks to be included in patterns. Basically, since code blocks
are now handled by the perl parser within literal patterns, runtime
patterns are handled by taking the (assembled at runtime) pattern,
and feeding it back through the parser via the equivalent of
eval q{qr'the_pattern'},
so that run-time (?{..})'s appear to be literal code blocks.
When this happens, the global flag PL_reg_state.re_reparsing is set,
which modifies lexing and parsing in minor ways (such as whether \\ is
stripped).
Now, I'm in the slow process of trying to eliminate global regex state
(i.e. gradually removing the fields of PL_reg_state), and also a change
which will be coming a few commits ahead requires the info which this flag
indicates to linger for longer (currently it is cleared immediately after
the call to scan_str().
For those two reasons, this commit adds a new mechanism to indicate this:
a new flag to eval_sv(), G_RE_REPARSING (which sets OPpEVAL_RE_REPARSING
in the entereval op), which sets the EVAL_RE_REPARSING bit in PL_in_eval.
Its still a yukky global flag hack, but its a *different* global flag hack
now.
For this commit, we add the new flag(s) but keep the old
PL_reg_state.re_reparsing flag and assert that the two mechanisms always
match. The next commit will remove re_reparsing.
|
| | |
| |
| |
| |
| |
| |
| | |
These were temporarily removed a few commits ago to make rebasing easier.
(And since the code's been simplified in the conflicting branch, not so
many debug statements had to be added back as were in the original).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[perl #116823]
In re_op_compile(), there were two different code paths for compile-time
patterns (/foo(?{1})bar/) and runtime (/$foo(?{1})bar/).
The code in question is where the various components of the pattern
are concatenated into a single string, for example, 'foo', '(?{1})' and
'bar' in the first pattern.
In the run-time branch, the code assumes that each component (e.g. the
value of $foo) can be absolutely anything, and full magic and overload
handling is applied as each component is retrieved and appended to the
pattern string.
The compile-time branch on the other hand, was a lot simpler because it
"knew" that each component is just a simple constant SV attached to an
OP_CONST op. This turned out to be an incorrect assumption, due to
overload::constant qr overloading; here, a simple constant part of a
compile-time pattern, such as 'foo', can be converted into whatever the
overload function returns; in particular, an object blessed into an
overloaded class. So the "simple" SVs that get attached to OP_CONST ops
can in fact be complex and need full magic, overloading etc applied to
them.
The quickest solution to this turned out to be, for the compile-time case,
extract out the SV from each OP_CONST and assemble them into a temporary
SV** array; then from then onwards, treat it the same as the run-time case
(which expects an array of SVs).
|
| | |
| |
| |
| | |
(only whitespace changes)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When assembling a compile-time pattern from a list of OP_CONSTs (and
possibly embedded code-blocks), there were separate code paths for a
single arg (a lone OP_CONST) and a list of OP_CONST / DO's.
Unify the branches into single loop.
This will make a subsequent commit easier, where we will need to do more
processing of each "constant".
Re-indenting has been left to the commit that follows this.
|
| | |
| |
| |
| | |
and eliminate one local var.
|
| | |
| |
| |
| | |
(whitespace changes only)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When compiling a regex, something like /a$b/ that parses two two args,
was treated in a different code path than /$a/ say, which is only one arg.
In particular the 1-arg code path, where it handled "" overloading, didn't
check for a loop (where the ""-sub returns the overloaded object itself) -
the N-arg branch did handle that. By unififying the branches, we get that
fix for free, and ensure that any future fixes don't have to be applied to
two separate branches.
Re-indented has been left to the commit that follows this.
|
| |/
|
|
|
|
|
| |
These four DEBUG_PARSE_r()'s were recently added to a block I code
which I have just been extensively reworking in a separate branch.
Temporarily remove these statements to allow my branch to be rebased;
I'll re-add them (or similar) afterwards.
|
| | |
|
| |
|
|
|
|
|
|
| |
perl_setup.com gets installed, so we might as well run it from
where we have it rather than copying it somewhere.
And we really shouldn't be recommending putting things in sys$share,
even as a second choice.
|
| |
|
|
| |
Patch submitted by Dmitry Karasik++. For: RT #117519
|
| |
|
|
|
|
|
|
|
|
| |
As of 5.18.0, Perl on VMS can (at last) be built in and installed
from a directory having dots in the name, so it is no longer
necessary to rename the top-level source directory before building.
The pertinent instructions have been removed from README.vms, so
we also no longer need to update the version number that was
embedded in those instructions.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In commit 3c3ecf18c35ad7832c6e454d304b30b2c0fef127, I mistakenly added
documentation for a non-existent macro. It turns out that only the
variants listed for that macro exist, and not the base macro. Since we
are in code freeze, the solution has to be not to change code by adding
the base macro, but to delete the documentation, or change it to refer
to just the existing versions. In order to not cause an entry that is
anomalous to the others, for this release, I'm just getting rid of the
documentation.
|
| |
|
|
| |
hash randomization logic
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to resolve these three related tickets:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
[perl #117319] Can't include perl.h without linking to libperl
[perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)
This patch changes S_croak_memory_wrap from a static (but not inline)
function into an ordinary exported function Perl_croak_memory_wrap.
This has the advantage of allowing programs (particuarly probes, such
as in cflags.SH and Time::HiRes) to include perl.h without linking
against libperl. Since it is not a static function defined within each
compilation unit, the optimizer can no longer remove it when it's not
needed or inline it as needed. This likely negates some of the savings
that motivated the original commit 380f764c1ead36fe3602184804292711.
However, calling the simpler function Perl_croak_memory_wrap() still
does take less set-up than the previous version, so it may still be a
slight win. Specific cross-platform measurements are welcome.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the next patch, I have Perl_croak_memory_wrap defined in embed.fnc with
the 'nroX' flags, since this is a private function used by public macros.
I used the long form of the name Perl_croak_memory_wrap everywhere, and
used the 'o' flag so that embed.h wouldn't contain a useless #define
croak_memory_wrap Perl_croak_memory_wrap. Unfortunately, makedef.pl
(used by the Win32 build process) didn't know what to do with that entry
and created an entry Perl_Perl_croak_memory_wrap. Changing makedef.pl
to use the 'o' flag to decide whether to add the Perl_ prefix resulted
in over 50 other symbols changing in the output of makedef.pl. I don't
know if the changes are correct or if the 'o' flag is in error on those
entries in embed.fnc, but I don't have time to check them all out.
This patch just stops makedef.pl from adding a Perl_ prefix if there is
already one there.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The usages are as far as I know incorrect anyway. We resize
the hash bucket array based on the number of keys it holds,
not based on the number of buckets that are used, so this
usage was wrong anyway.
Another bug that this revealed is that the old code would allow
HvMAX(hv) to fall to 0, even though every other part of the
core expects it to have a minimum of 7 (meaning 8 buckets).
As part of this we change the hard coded 7 to a defined constant
PERL_HASH_DEFAULT_HvMAX.
After this patch there remains one use of HvFILL in core, that used
for scalar(%hash) which I plan to remove in a later patch.
|
| |
|
|
|
|
|
| |
The split patch introduced a buffer read overrun error in sv_dump() when
stringifying empty strings. This bug was always existant but was probably
never triggered because we almost always have at least one extflags set,
so it never got an empty buffer to show. Not so with the new compflags. :-(
|
