| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
BinGOs told me that this updated was all that was required,
and I chose to trust him.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265950
We do not yet know the extent of the problem.
|
| |
|
|
|
|
|
|
| |
This fixes #20090
These symbols were changed by fcbef0e to be defined in more
Configurations, but as @bram-perl pointed out, makedef.pl didn't also
change to export them in those expanded situations.
|
| |
|
|
|
|
|
|
|
| |
This unused variable dates back to when the file was first added. The code
was structured as a static C wrapper emulating the dlopen() API with the
native APIs, and then a copy of the existing XS code that called dlopen().
However, there is (and was) no need to keep it exactly this way, as the
wrapper is only visible inside this file, meaning that it does not need to
conform to any externally defined prototype.
|
| |
|
|
| |
real module version
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git-rev-parse HEAD^2` was used to detect if HEAD was a merge commit.
When HEAD is not a merge commit then HEAD^2 produces an error;
When HEAD is a merge commit then HEAD^2 points to the second parent.
The problem was that `git rev-parse "HEAD^2"` also produced output on STDOUT
which caused `$revision_range` to be set to something bogus.
Example:
$ git rev-parse HEAD^2 2>/dev/null ; echo $?
HEAD^2
128
$ git log HEAD^1..HEAD^2
fatal: ambiguous argument 'HEAD^1..HEAD^2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
The fix is to use --verify which doesn't give output on STDOUT for something invalid.
It does print an error on STDERR (for invalid things) which can be silenced using -q
$ git rev-parse --verify HEAD^2
fatal: Needed a single revision
$ git rev-parse -q --verify HEAD^2
$
For an actual merge commit:
$ git rev-parse -q --verify e91a97a^2
bee6601bbf238b5366ce11cd41f6b095bfeebfd8
(i.e. working as expected)
|
| |
|
|
|
|
|
|
|
| |
These messages are obsolete. They exist to tell perl not to complain
when it finds a matching diagnostic that isn't listed in perldiag. But
the messages don't get generated any more, so running the test without
them still passes.
Many of these were spotted by @bram-perl
|
| |
|
|
|
| |
These are clear enough without explanation in perldiag. There's a bunch
of them that can be represented by just one.
|
| |
|
|
|
| |
These are clear enough without explanation in perldiag. There's a bunch
of them that can really be represented by just one.
|
| |
|
|
| |
This diagnostic is the outlier of all the other ones.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running 'make_patchnum.pl' from a subdir then 'make_patchnum.pl'
failed to write a proper lib/Config_git.pl. That is: all values in it
were set to the empty string instead to the actual values.
Example:
$ cd perl5
$ mkdir foo && cd $foo
$ ../miniperl -I../lib ../make_patchnum.pl
Updating 'git_version.h' and 'lib/Config_git.pl'
$ cat ../lib/Config_git.pl
######################################################################
# WARNING: 'lib/Config_git.pl' is generated by make_patchnum.pl
# DO NOT EDIT DIRECTLY - edit make_patchnum.pl instead
######################################################################
$Config::Git_Data=<<'ENDOFGIT';
git_commit_id=''
git_describe=''
git_branch=''
git_uncommitted_changes=''
git_commit_id_title=''
This got broken in commit 3f1788e11f2685299067ac0f8d3e4fd141a5b5cd which
added support for -Dmksymlink.
That commit basically assumed that the stating point was always '.' and
that the './.git' directory exist. Neither are true when the command is
run from inside a subdir.
The proper thing to do is to first find the `$root` directory and then
check if it's in -Dmksymlinks target dir. (Luckily all that code already
exists, we just need to move the -Dmksymlinks logic a bit down.)
With this change applied:
$ ../miniperl -I../lib ../make_patchnum.pl
Updating 'git_version.h' and 'lib/Config_git.pl'
$ cat lib/Config_git.pl
######################################################################
# WARNING: 'lib/Config_git.pl' is generated by make_patchnum.pl
# DO NOT EDIT DIRECTLY - edit make_patchnum.pl instead
######################################################################
$Config::Git_Data=<<'ENDOFGIT';
git_commit_id='c589bf60082d119a14e11ef05a77fed6d36aba4b'
git_describe='v5.37.2-170-gc589bf6'
git_branch='bram/fix-make_patchnum-in-subdir'
git_uncommitted_changes='0'
git_commit_id_title='Commit id:'
git_commit_date='2022-08-16 15:49:38 +0200'
ENDOFGIT
Note:
- to build on Windows one must do a `cd win32` before building. This is how
I noticed the file was incorrect.
- I've tested running make_patchnum from:
* the root
* a subdir
* a '-Dmksymlinks' target dir
* a subdir inside a '-Dmksymlinks' target
(PS: I also fixed the indentation from tabs to 4 spaces)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #20085.
In the new POSIX API for thread-safe locales, introduced in the 2008 version
of the standard, no method was defined to find out what the current locale
is. (That has finally been changed in the 2017 version, but I am
unaware of any boxes (accessible to me) implementing it.)
Darwin added their own extension to accomplish this, and Windows instead
used an extension to the old API to accomplish thread-safety. And glibc
has their own, hidden extension, which it's possible to Configure Perl
to use, but, since, it's not documented, it is not enabled by default.
Perl maps the old API to the new one when compiled for threads, and
where thread-safety is available. On Configurations where there isn't
the ability to query the current locale, it itself keeps a record of
that information, maintained from start-up of the process.
Commit 19e550d changed things so that when calling the function that
changes a category's locale, if the value to change to is the same as it
already was, it is a no-op.
But LC_ALL is precisely the sum of all the other locale categories. If
any one of them changes, LC_ALL must be updated. There are occasions
where all subcategories are updated in a tight loop, and, to save
unnecessary work, only the final iteration updates LC_ALL (as each
iteration would throw away the results of the previous iteration).
The blamed commit inadvertently caused the code to skip updating LC_ALL
when the final iteration wouldn't result in a change in the locale of
its category, whereas LC_ALL should have been updated on that iteration
if any previous iteration affected a change.
This new commit causes LC_ALL to always be updated on the final
iteration, regardless of what happened in the previous ones. To only
update it when absolutely necessary, we would have to have an extra
internal state (meaning a new PL_ interpreter variable) indicating that
we are in a loop and whether changes have occurred while in that loop.
That's certainly feasible, but I don't think the extra complexity is
worth it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These two functions take as input a parameter that is three-valued.
Basically, the meanings are 'true', 'false', and 'special'. This
changes them to use an enum instead, so that the compiler will detect if
they are being called with an unanticipated value.
The parameter names now become more self-documenting.
Comments are added to better explain what 'special' means, and why it
exists.
|
| |
|
|
|
|
| |
This loop recalculates LC_ALL on the final non-LC_ALL iteration, and
then it did an extra iteration, just to recalculate LC_ALL. This is
unnecessary and could cause memory leaks.
|
| |
|
|
|
| |
There is no attribute visibility on cygwin apparently, and the warnings
seem to overwhelm the cygwin build process.
|
| |\
| |
| |
| |
| | |
These commits were inadvertently left out of
2fbb1a06df7219e842b3a2a0c9dcbab10de433fc
|
| | |
| |
| |
| |
| | |
It doesn't matter much, but some warnings might be output by doing the
'use locale' before turning off warnings.
|
| | | |
|
| |/
|
|
|
|
|
|
| |
This commit causes us not to view unsupported locales as legitimate for
testing. Core dumps occurred on some platforms without this.
It looks for a diagnostic that the next commit in this series will
generate.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building on Windows one must provide a value for 'CCHOME'.
The value of 'CCHOME' is used to set the value of 'CCLIBDIR' and 'CCINCDIR'.
(These eventually become `$Config{libpth}` and `$Config{incpath}`.)
When 'CCHOME' is incorrectly set the build mostly works; what fails
is building cpan/Win32 and this then fails with non-obvious errors such as:
Warning (mostly harmless): No library found for -luserenv
Warning (mostly harmless): No library found for -lwinhttp
...
g++ Win32.def -o ....
C:/.../ld.exe: ... undefined reference to `WinHttpCrackUrl'
...
collect2.exe: error: ld returned 1 exit status
gmake[1]: *** [Makefile:472: ..\..\lib\auto\Win32\Win32.dll] Error 1
gmake[1]: Leaving directory 'C:/Perl/perl5/cpan/Win32'
Unsuccessful make(cpan/Win32): code=512 at ..\make_ext.pl line 584.
Make this a bit more obvious by checking if the path(s) specified in
'CCLIBDIR' and 'CCINCDIR' actually exist.
If these do not exist then stop the build process at an early stage with
a clear(er) error.
Example error:
..\miniperl.exe -I..\lib config_sh.PL ...
'CCLIBDIR' contains the following non-existing paths:
C:\MinGW\lib
C:\MinGW\x86_64-w64-mingw32\lib
C:\MinGW\lib\gcc\x86_64-w64-mingw32\8.3.0
Did you provide a correct value for the 'CCHOME' option?
(This check can be skipped by using the SKIP_CCHOME_CHECK=1 option)
gmake: *** [GNUmakefile:1176: ..\config.sh] Error 1
Some notes:
- This check can be skipped/overridden by adding 'SKIP_CCHOME_CHECK=1'
on the make cmd line. (I added this because I don't know if there are
valid use cases for having a non-existing path in 'libpth'/'incpath')
- My first idea was to do this in the Makefile/GNUmakefile at a very early
stage but that is more complex to do and the resulting code is messy/ugly.
So instead I opted to do it in 'config_sh.PL' since this is the
first(/only) place that uses these vars.
- I (only) tested on Windows 10 using GNU Make and gcc
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
t/loc_tools.pl is a set of utility functions for testing scripts to use
to query the current platform to see if various capabilies exist on the
platform.
Locale handling is not very uniform across platforms, and these
utilities are to allow test scripts to easily skip tests, or to find
valid locales to test on.
Some platforms that are bare-bones, or which emphasize security, turn off
all or most locale handling altogether. Others accept just about any
garbage as parameters to their functions, while doing nothing. Others
act reliably.
Locale-related bugs reported to vendors don't tend to get fixed. We
reported an incorrect symbolic link about Darwin long ago, trivial to
fix, but last I checked no action had been taken. glibc has a warnocked
bug reported by us, as does freebsd. (There may be others.) I happen
to have the link to the freebsd one handy, in case you're interested,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255646
This series of commits adds some defenses against locale issues.
A locale name is legally allowed to be anything, opaque to the caller as
to its meaning. The only requirement is that what setlocale returns as
a value for a locale should be able to be passed into a future setlocale
as valid input. Windows has at least one locale that violates this.
However, the X/Open Portability Guide (XPG) does specify a locale name
syntax, and it appears that most modern Unixy systems tend to follow
this.
The problematic Windows locale has a comma in its name; commas are
illegal in the XPG specification. One of the commits in this series
hence won't return a locale whose name contains a comma. Hence a
user of these utilities doesn't have to cope with a one-off locale name
of this form. (There are previously existing checks in loc_tools.pl
that keep other glitchy locales from being returned).
Undocumented, AFAICT, is that, on some platforms (but I don't think all)
a locale category that has associated strings has to have LC_CTYPE set
to the same locale as that category for things to work. An example is
LC_TIME where the names of the days of the week, etc, are strings. Core
dumps have occurred when LC_CTYPE and LC_TIME aren't the same value.
One commit here makes sure that in testing a category, LC_CTYPE is
brought along, so as to avoid a potential core dump
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a problem in some buggy Windows versions. A Macedonian
sub-locale has a comma in its returned name, and Windows can't parse its
own name.
This addition keeps locales with this bug from being tested, as the XPG
standard doesn't allow them.
|
| | |
| |
| |
| |
| |
| | |
This verifies that we can restore a locale that we were previously in,
and makes sure that we don't stay in a locale that doesn't work well.
Doing so has led to crashes.
|
| | |
| |
| |
| |
| | |
Move the code that returns failure into the loop, so won't keep
iterating if failure is going to happen anyway.
|
| | |
| |
| |
| |
| |
| |
| | |
This function is used to see if a locale actually works on the current
platform. I was not fully aware of the glitches if a category is in one
locale, and LC_CTYPE is in another. This makes sure they are both the
same; and this results in some simplification.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This test module is 'required' from other perl test files. If it
encounters an error, it doesn't know how to report it. What it does is
call fail() if available, and a home-grown one otherwise. Prior to this
commit the home-grown version just made all tests number 0. This commit
changes that to make them sequentially numbered from a very high
starting one, so as not to interfere with the outer calls.
|
| | |
| |
| |
| | |
This is for future commits to call after it is defined
|
| |/
|
|
|
|
|
|
|
| |
category_excluded() is a better name for what the current name
'is_category_valid" does. And it turns out that we need to use this
function on (those few) systems that don't have LC_CTYPE to avoid
executing code that depends on LC_CTYPE.
And we do need an improved is_category_valid() for other checks.
|
| |
|
|
|
|
| |
This is also initialized in locale.c
Spotted by Tony Cook.
|
| |
|
|
| |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255646
|
| |
|
|
|
| |
This was a copy/paste error. The message wasn't changed to match the
new situation it was being called from.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `$(CONFIGPM}` target depends on the 'lib/Config_git.pl' file which
is created by the '..\git_version.h' target (this runs `make_patchnum.pl`
which creates both files).
Build log when dependency is missing:
..\miniperl.exe -I..\lib ..\configpm --chdir=..
written lib/Config.pod
updated lib/Config.pm
updated lib/Config_heavy.pl
Warning: failed to load Config_git.pl, something strange about this perl...
..\miniperl.exe -I..\lib config_h.PL "ARCHPREFIX="
Running config_h.PL
Writing config.h
Warning: failed to load Config_git.pl, something strange about this perl...
config.h has changed
(....)
..\miniperl.exe -I..\lib ..\make_patchnum.pl
Updating 'git_version.h' and 'lib/Config_git.pl'
-> It first ran `configpm` and only later it ran `make_patchnum.pl`
Build log with the dependency:
..\miniperl.exe -I..\lib ..\make_patchnum.pl
Updating 'git_version.h' and 'lib/Config_git.pl'
(...)
..\miniperl.exe -I..\lib ..\configpm --chdir=..
written lib/Config.pod
updated lib/Config.pm
updated lib/Config_heavy.pl
..\miniperl.exe -I..\lib config_h.PL "ARCHPREFIX="
Running config_h.PL
Writing config.h
config.h has changed
Notes:
- in ./Makefile.SH the same dependency was added in
commit 744ac0eac539aead596d9fa09cc15a20b09a5884 (and later updated in
commit 0f13ebd5d71f81771c1044e2c89aff29b408bfec)
- in ./win32/Makefile the same dependency was added in
commit 680b2c5ee3b53c627074192b3cf14416a24da6ea (the dependency fix
however was not mentioned in the commit message)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code in 9fdd7fc4796d89d16dceea42f2af91e4fde296ed broke the g++ builds,
Basically after the commit the code looked like:
switch (o->op_type) {
...
case OP_SASSIGN:
...
OP* rhs = cBINOPx(o)->op_first;
OP* lval = cBINOPx(o)->op_last;
...
break;
case OP_AASSIGN: {
g++ does not allow this and errors with:
peep.c:3897:14: error: jump to case label
3897 | case OP_AASSIGN: {
| ^~~~~~~~~~
peep.c:3844:17: note: crosses initialization of 'OP* lval'
3844 | OP* lval = cBINOPx(o)->op_last;
| ^~~~
peep.c:3843:17: note: crosses initialization of 'OP* rhs'
3843 | OP* rhs = cBINOPx(o)->op_first;
| ^~~
This happens because `rhs` and `lval` are not scoped in the case statement
so it could fall through to the next case.
The solution is to scope them which this commit now does by adding a
separate scope for `OP_SASSIGN` (similar to `OP_AASSIGN`).
Fixes #20108
|
| | |
|
| |
|
|
|
|
|
|
| |
Also do a build with 'g++' since it can catch more errors.
(I accidentally broke builds with g++ and that commit got merged
on blead; smokers then reported build failures with g++ but it would
have been nicer if I knew this before it got merged.)
|
| |
|
|
|
|
|
|
|
| |
Implemented as a static inline function call, so that it can return the
padname pointer itself. This would allow use in expressions such as
ptr->field = PadnameREFCNT_inc(pn);
That makes it similar to the familiar SvREFCNT_inc() macro.
|
| |
|
|
|
| |
The wording has been left generic, since other such optimizations
are in the PR queue and could just be tacked on the end later.
|
| | |
|
