| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
(Also perl #118105.)
This allows *ARGV->can("print") to work as long as IO::Handle is
loaded. This translates into UNIVERSAL::can(\*ARGV,"print"). This
commit also changes UNIVERSAL::can to accept a plain *ARGV as well.
UNIVERSAL::can("ARGV",...) is left as it is (ARGV is treated as a pack-
age name), because changing that requires a bigger patch, and I don’t
know when I will get to it.
|
|
|
|
| |
Because on VMS a zero-length extension still has a dot.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now ExtUtils::Miniperl has the master version of {mini,}perlmain.c and is
checked into the repository. miniperlmain.c is now generated by a script
in regen/ which uses ExtUtils::Miniperl.
Tweak ExtUtils::Miniperl::writemain() to take an optional first argument,
a reference to a file handle. This permits the regen script to use the
regen_lib.pl functions for file opening/closing/renaming and TAP generation.
For now check in ExtUtils::Miniperl minimally modified from the version
generated by the former minimod.pl. The next commit will tidy it up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A regular expression invoked inside a regular expression code block
can cause other code blocks in the same outer regular expression to
see the wrong values in $1.
PL_curpm holds a pointer to the match operator from which $1, $2, etc.
get their values.
Normally PL_curpm is set at the end of a match.
When code blocks are embedded inside a regular expression, PL_curpm
is set during a match to point to PL_reg_curpm, which is a dummy op
pointing to the current regular expression.
S_setup_eval_state is called at the beginning of regexp execution.
It is responsible for setting up PL_regcurpm and making PL_curpm
point to it.
Code blocks are executed using the multicall API. PUSH_MULTICALL
records the value of PL_curpm and POP_MULTICALL makes sure that the
previous value of PL_curpm is restored.
Executing a code block can cause PL_curpm to point to something else.
Since we don’t necessarily do POP_MULTICALL between code block calls
within a single regular expression (sometimes we do, depending on
backtracking), PL_curpm may not have been restored when a second code
block fires. So we have to restore it to point to PL_reg_curpm manu-
ally after calling a code block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The code to do warnings on invalid prototypes was a chunk
of 70 or so lines inside the core lexer. It also had the
side effect of removing spaces from the prototype as part
of its check for warnings.
This validation code is now just a validation, printing
out warnings if and only if warnings are enabled,
and leaving the source SV untouched.
|
| |
|
|
|
|
|
| |
This had the wrong syntax, but it wasn't caught because it is TODO
anyway.
|
|
|
|
|
|
|
| |
This simplifies the VMS Makefile. It would have simplified the VMS Makefile
further if it had had the correct rules to delete [.lib.VMS]Filespec.pm
which are now no longer needed. (The generated ext/VMS-Filespec/DESCRIP.MMS
will now take care of this.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are various various things that break the test's assumptions.
1) If Encode is a static extension, then Configure has special case logic
to add Encode/* as static extensions
2) -Uusedl causes Encode to be a static extension, and drops building
XS::APItest and XS::Typemap
3) Any use of -Dnoextensions to choose not to build a extension is not known
by the test
If any of these are true, FindExt::extensions() and $Config{extensions} will
differ, and most of the tests are going to fail. Moreover, failure doesn't
tell us anything interesting. So don't run those tests.
|
| |
|
|
|
|
|
|
| |
Use a ternary instead of if/unless on the same $^O test.
Use a loop to call FindExt::scan_ext()
As FindExt exports nothing, we can require it rather than using it.
|
|
|
|
|
| |
FindExt::apply_config() mimic's Configure's logic, which means that FindExt's
idea of which extensions should be built is consistent with Configure's.
|
|
|
|
| |
See rt ticket #118675 for background on this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This segfault is a result of an optimization that can leave the
compilation in an inconsistent state.
/f{0}/
doesn't match anything, and hence should be removable from the regex for
all f. However,
qr{(?&foo){0}(?<foo>)}
caused a segfault. What was happening prior to this commit is that
(?&foo) refers to a named capture group further along in the regex.
The "{0}" caused the "(?&foo)" to be discarded prior to setting up the
pointers between the two related subexpressions; a segfault follows.
This commit removes the optimization, and should be suitable for a
maintenance release.
One might think that no one would be writing code like this, but this
example was distilled from machine-generated code in Regexp::Grammars.
Perhaps this optimization can be done, but the location I chose for
checking it was during parsing, which turns out to be premature. It
would be better to do it in the optimization phase of regex compilation.
Another option would be to retain it where it was, but for it to operate
only on a limited set of nodes, such as EXACTish, which would have no
unintended consequences. But that is for looking at in the future; the
important thing is to have a simple patch suitable for fixing this
regression in a maintenance release.
For the record, the code being reverted was mistakenly added by me in
commit 3018b823898645e44b8c37c70ac5c6302b031381, and wasn't even
mentioned in that commit message. It should have had its own commit.
|
|
|
|
|
|
| |
Whatever the executable is named at the top level, it's always symlinked
as ./perl in t, so there's no need to set an environment variable to
override the expected name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the targets:
perl.pixie perl.pixie.atom perl.pixie.config perl.pixie.irix perl.third
perl.third.config
It's still possible to run the actions these targets "by hand", if desired.
This commit removes the convenience targets from the Makefile, reducing its
complexity. It also removes the related support scripts testall.atom and
thirdclean from Porting/
pixie is a performance analysis tool for Irix and Tru64
Third Degree is a memory checker tool for Tru64
Given that Tru64 went out of support at the end of 2012, and Irix goes out
of support at the end of 2013, it's very unlikely that anyone is still
actively profiling or debugging perl on either platform, and hence using
these targets. It's been several years since we've even had a regular bug
report from either platform.
|
|
|
|
|
|
|
|
| |
In principle it shouldn't need libraries, but an eval of a utf8
constant now triggers automatic loading of utf8.pm, and it was
looking for that in the usual @INC locations set at configuration
time. Which just might match an installed perl rather than the
perl being tested. So make sure we get the correct libraries.
|
| |
|
|
|
|
|
|
|
|
| |
Make the two checks of possible poor uses of C<>
pedantic checks.
Allow --pedantic to turn on those tests in addition to
the environmnt variable.
|
|
|
|
|
|
|
| |
To run these tests, set PERL_POD_PEDANTIC in the environment.
This needs further testing, at least, to ensure that it behaves correctly
when regenerating the known problem files.
|
|
|
|
|
|
|
| |
This reverts commit f26da014a698383ac348973050af3e754752e6ab.
Conflicts:
t/porting/known_pod_issues.dat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This format string allows char*s to be interpolated with the
utf8ness and length specified as well, avoiding the need to create
extra SVs:
Perl_croak(aTHX_ "Couldn't twiggle the twoggle in \"%"UTF8f"\"",
UTF8fARG(is_utf8, len, s));
This is the second attempt.
I screwed up in commits 1c8b67b38f0a5 and b3e714770ee1 because
I didn’t really understand how varargs functions receive their
arguments.
They are like structs, in that different members can be different
sizes. So therefore both ends--the caller and the called--*must* get
the casts right, or the data will be corrupted.
The main mistake I made was to use %u in the format for the first
argument and then retrieve it as UV (a simple typo, I meant unsigned
int or U32--I don’t remember).
To be on the safe side, I added a UTF8fARG macro (after SVfARG), which
(unlike SVfARG) takes three arguments and casts them explicitly, mak-
ing it much harder to get this wrong at call sites.
|
|
|
|
|
|
|
|
|
|
|
| |
because:
a) I think it better demonstrates the fix, the following failed without
the patch:
./perl -Ilib -le 'my $proto = "\x{30cd}"; eval "sub f($proto) {}"; print prototype(\&f); print prototype(\&f) eq $proto'
b) I can envision bugs that might preserve UTF-8 but mis-manage the content
|
|
|
|
|
|
|
|
|
|
|
| |
Because of a missing SvUTF8_on() in cv_clone(), these two were different:
use utf8;
eval " sub foo ($;\x{30cd});"
eval "my sub foo ($;\x{30cd});"
Because the lexical version would lose the UTF8 flag in the
prototype.
|
|
|
|
|
| |
This is a slightly expanded (or bloated) version of the patch
Dennis Kaarsemaker <dennis@kaarsemaker.net> submitted.
|
|
|
|
|
|
|
| |
This included some refactoring to break down the original
large if block into smaller, more manageable chunks,
although the only functional change was to pass the two
string buffers through S_strip_spaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
‘Ambiguous use of * resolved as operator *’: This message can occur in
cases where there is no multiplication operator, so what it is saying
is completely wrong.
When the lexer parses a bareword, it looks at the previous character
and warns if it happens to match /[*%&]/, so foo**bar and foo&&bar
result in this warning, as does print $%foo.
The purpose of the code is to catch *bar *bar or &black &sheep.
To avoid false positives, when emitting one of the three operators
* % & the lexer can record that fact, so when it sees a bareword pre-
ceded by one of those three characters, instead of guessing that the
infix operator was used, it will *know*.
The test cases added also trigger ‘Bareword found where operator
expected’. I don’t know whether that should change, but at least the
current behaviour is tested, so we will know when it does change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The arguments following the first were using the context the enclosing
function was called in.
sub context { warn qw[void scalar list][wantarray + defined wantarray ] }
sub foo { sort +context, context; print "------\n"; }
foo;
$_ = foo;
[foo];
__END__
Output:
list at - line 1.
void at - line 1.
------
list at - line 1.
scalar at - line 1.
------
list at - line 1.
list at - line 1.
------
Extend the list context to all arguments.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since $a and $b are aliased to the actual scalars being sorted, and
since they can be modified, the list of items needs to be in lvalue
context, like the arguments to grep. Otherwise implementation
details leak through, in that sort{$a=1} $_,... will modify $_, but
sort{$a=1} $#_,... will fail to modify $#_.
The way I have written the loop and if() condition (the if inside the
loop) may seem odd and inefficient, but the next commit will take
advantage of that.
|
|
|
|
|
|
|
|
|
| |
$ ./perl -Ilib -e '@a=1..2; eval { @a=sort{die} @a }; warn "ok so far\n"; @a = 1'
ok so far
Modification of a read-only value attempted at -e line 1.
If something goes wrong inside the sort block and it dies, we still
need to make sure we turn off the read-only flag on that array.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 670610ebb17508101065cc5f5ecfe616aace5335.
This and the other UTF8f patch are causing significant problems on some
configurations on 32-bit platforms. We've decided to revert them until
they can be resubmitted after the kinks get ironed out.
|
|
|
|
|
|
|
| |
/\87/ is parsed through a different code path than /foo\87/ so we
test that they both work properly when there are sufficient capture
buffers defined. We test the fail cases in the re/re_tests corpus,
but the success cases are easier managed in re/pat.t.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 726ee55d introduced better handling of things like \87 in a
regex, but as an unfortunate side effect broke latex2html.
The rules for handling backslashes in regexen are a bit arcane.
Anything starting with \0 is octal.
The sequences \1 through \9 are always backrefs.
Any other sequence is interpreted as a decimal, and if there
are that many capture buffers defined in the pattern at that point
then the sequence is a backreference. If however it is larger
than the number of buffers the sequence is treated as an octal digit.
A consequence of this is that \118 could be a backreference to
the 118th capture buffer, or it could be the string "\11" . "8". In
other words depending on the context we might even use a different
number of digits for the escape!
This also left an awkward edge case, of multi digit sequences
starting with 8 or 9 like m/\87/ which would result in us parsing
as though we had seen /87/ (iow a null byte at the start) or worse
like /\x{00}87/ which is clearly wrong.
This patches fixes the cases where the capture buffers are defined,
and causes things like the \87 or \97 to throw the same error that
/\8/ would. One might argue we should complain about an illegal
octal sequence, but this seems more consistent with an error like
/\9/ and IMO will be less surprising in an error message.
This patch includes exhaustive tests of patterns of the form
/(a)\1/, /((a))\2/ etc, so that we dont break this again if we
change the logic more.
|
|
|
|
| |
Commit 83ced756 broke the --add_link option to podcheck.t. Now fixed
|
| |
|
| |
|
|
|
|
|
| |
The perldiag entry has differed from the actual error since both were
added in a1b950687051c.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|