summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add 5.35.5 to perlhistv5.35.5Leon Timmermans2021-10-211-0/+1
|
* Update perldelta for 5.35.5 releaseLeon Timmermans2021-10-211-211/+92
|
* Update Module::CoreList for 5.35.5Leon Timmermans2021-10-211-2/+104
|
* inline.h: _BitScanForward64 is available only on 64-bit architecturesTomasz Konojacki2021-10-211-1/+1
| | | | Fixes #19205
* inline.h: remove superfluous Visual C++ version checksTomasz Konojacki2021-10-211-5/+5
| | | | We no longer support Visual C++ 2012 and older.
* Revert "Introduce a "declaration after statement" into inline.h"Leon Timmermans2021-10-201-1/+3
| | | | | | | This reverts commit 632ce96a35d784df9e43bc8ad87b4e8f1f24a590. Sereal hasn't been fixed yet to deal with the fallout of this change, so we postpone this change for a later moment
* Add dropping old MSVC++ (pre-VC12) to perldeltaLeon Timmermans2021-10-201-2/+4
|
* Perl_newHVhv should use share_hek_hek() instead of share_hek_flags()Nicholas Clark2021-10-201-7/+10
| | | | | | | share_hek_hek() manipulates the shared HEK's reference count directly, without needing to find it in the shared string table. It was added after Perl_newHVhv() was implemented, and no-one noticed that it could be used there.
* Fix the build and tests when NODEFAULT_SHAREKEYS is definedNicholas Clark2021-10-204-3/+33
| | | | | Defining this macro causes newHV() to create hashes without shared hash key scalars. The default is that hashes are created with shared hash keys.
* Perl_newHVhv() did not correctly copy hashes with non-shared keysNicholas Clark2021-10-201-0/+8
| | | | | | | | It created a hash built with non-shared keys, but left the "shared keys" flag set on the hash. This hasn't been spotted in 20 years, which shows just how much we use hashes with unshared keys.
* hv_delete_common() must not call GvAV() on a non-GVNicholas Clark2021-10-202-2/+10
| | | | | | | | | | | | | | | | | | | | | | | hv_delete_common() must update isa magic stash records when *ISA is deleted (see commit 6146d9e1c87d449f) However, it's only valid to use the macro GvAV() on an SV that is a GV. Previously the code was not checking this, hence if someone deliberately manipulated the symbol table to first store something other than a typeglob, and then delete that entry from the symbol table, then (at best) an assertion would fail, at worst illegal memory accesses. Do this by moving the check for `SvTYPE(sv) == SVt_PVGV` up to the if() that governs both code blocks. Note that you could only trigger this bug by running code that manipulates symbol tables directly. Compilation of Perl code would not hit it, nor could user-controlled data in executing Perl programs, unless the programs both contain code to manipulate symbol tables, and permit unvalidated user data to reach those code paths. (Such programs are likely insecure already, as their control flow can be subverted by user controlled data without requiring any interpreter bugs.)
* op.c: use %zd to format PADOFFSET valuesDagfinn Ilmari Mannsåker2021-10-201-2/+2
| | | | | PADOFFSET is SSize_t, so %lu is wrong even if long and SSize_t are the same size.
* Add NetWare removal to perlportLeon Timmermans2021-10-201-0/+12
|
* Add nick@i3.procura.nl to mailmapLeon Timmermans2021-10-201-0/+1
|
* Update Encode to 3.16Leon Timmermans2021-10-194-6/+6
|
* Update Scalar-List-Util to 1.60Leon Timmermans2021-10-1918-272/+117
|
* Update experimental to 0.025Leon Timmermans2021-10-192-4/+8
|
* Update Test-Simple to 1.302188Leon Timmermans2021-10-1973-88/+138
|
* Remove old MSVC++ (pre-VC12) support from Windows MakefilesSteve Hay2021-10-193-317/+64
| | | | | | | | | | | | | | | | | | | | Also remove the Platform SDK 2003 SP1/R2 64-bit compiler since (having just tried it) it no longer builds perl because it doesn't allow mixed code and declarations. Also remove mention of the Windows SDK since it doesn't appear to contain the compiler or linker any more. This page says that the VC++ 2010 compiler and linker were included in the Windows 7 SDK but then makes no mention of it for the Windows 8 SDK: https://docs.microsoft.com/en-us/previous-versions/visualstudio/windows-sdk/ff660763(v=vs.110) The page notes that it is no longer being updated, but the whole of the C:\Program Files (x86)\Windows Kits folder on my system (which contains 8.0, 8.10 and 10) does not contain any cl.exe or link.exe. I've re-worded some of the if/else conditions in the makefiles to pick out earlier versions rather than later versions. Thus, the current versions become the "else" case, which means that the next version of Visual C++ is more likely to work without requiring any changes.
* don't overwrite the faked up type details for hv-with-auxTony Cook2021-10-191-1/+1
| | | | CID 340472
* `for my($k, $v) (%hash)` should not be a syntax errorNicholas Clark2021-10-194-29/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No-one had thought to test for this explicitly. After all, both `for my $foo ...` and `for my$foo ...` are valid syntax, so tweaking the C lexer code to add an optional '(' should work, surely? The problem was that, *as was*, the lexer code didn't "accept" those two syntax variants the way the comments would suggest. `for my $foo ...` was treated as 1) we saw 'my ' 2) we saw the dollar sign 3) success! but `for my$foo ...` was treated as 0) we didn't see 'my ' or 'our ' 1) we saw the literal string 'my' which is valid as a package name 2) we saw the dollar sign 3) success! ie some sort of mangled variant of `for my Dog $spot ...` without 'my' *but* as the lexer was happy with what it saw, it returned that the input stream was valid for a "for" token, and control continues to the grammar. The grammar, of course, didn't make these mistakes, so parsed everything properly and built the correct optree. (And, if presented with `for Dog $spot (...)` the grammar wouldn't match, so all invalid code was correctly rejected) However, all this came unstuck with `for my($k` because that didn't mis-tokenise as some crazy package name 'my(', so it reported a syntax error. Hence rewrite yyl_foreach() to actually tokenise everything correctly. "Correctly", to be clear, is bug-for-bug compatible with the current emergent behaviour for various corner cases for "parses and runs" vs "syntax error". We don't always report identical error messages for certain syntax errors, where the precise message reported was itself emergent behaviour from the bugs in the previous implementation.
* for CORE::my $var (...) {} is legal syntax, hence test itNicholas Clark2021-10-181-0/+37
| | | | | | | | | | | | We had tests for CORE::state, but not CORE::my or CORE::our. It happens that they are all legal syntax, but seemingly more be accident than design. They are only accepted by yyl_foreach() as a quirk of the current implementation. Note that for my Dog $spot (...) {} is legal, but not CORE::my. our Dog is legal, CORE::our is not. Neither state Dog nor CORE::state are legal. These are all emergent behaviour of the parser - do not take these tests as "correct", merely as verifying that current behaviour doesn't change unless we intended it to.
* add customized entries for the latest Memoize changesTony Cook2021-10-182-0/+5
|
* Fix Memoize tests, where GDBM_File is involvedSergey Poznyakoff2021-10-182-3/+3
| | | | | | * cpan/Memoize/t/errors.t: Use GDBM_NEWDB as the flags argument when tying to GDBM_File. * cpan/Memoize/t/tie_gdbm.t: Likewise.
* perlop - clarify that hyphens are interpreted literally in tr with single quotesDan Book2021-10-171-1/+2
|
* install libgdbm and libdb in GitHub ActionsTomasz Konojacki2021-10-151-4/+28
| | | | This ensures that DB_File and GDBM_File will be built and tested.
* disable LeakSanitizer in GitHub ActionsTomasz Konojacki2021-10-151-2/+4
| | | | | | It randomly fails with a fatal error for no apparent reason. Fixes #19189
* Merge branch 'pp_iter' into bleadRicardo Signes2021-10-1519-1353/+2467
|\
| * Pod improvements suggested by Matthew HorsfallNicholas Clark2021-10-153-9/+9
| |
| * for my ($foo,,, $bar) { ... } should parse as ($foo, $bar)Nicholas Clark2021-10-155-6/+46
| | | | | | | | | | Multiple commas between the lexicals in the list shouldn't change the parsing.
| * Test next, continue and redo with n-at-a-time for loopsNicholas Clark2021-10-151-0/+62
| |
| * Note why this if block in pp_iter is emptyNicholas Clark2021-10-151-0/+5
| |
| * perldelta for n-at-a-time for loops.Nicholas Clark2021-10-151-4/+10
| |
| * n-at-a-time for loops now warn by default (as 'experimental::for_list').Nicholas Clark2021-10-155-4/+56
| |
| * Add a new warning experimental::for_list.Nicholas Clark2021-10-153-6/+15
| |
| * Move reading CxTYPE(cx) out of the loop, to be clear that it doesn't change.Nicholas Clark2021-10-151-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move some other variable declarations into a tighter scope, and initialise variables at the point of declaration where possible. With the recent changes, the function consists of a 4-way switch inside a loop, where each iteration of the loop will take the same case in the switch. This implies a branch taken on each iteration of the loop, which is less efficient than the alternative structure of taking the branch once and then looping. However, the way the code is structured (particularly how two of the cases share code, by jumping sideways), means that rewriting it to "switch first" structure would not be clearer (and likely would also be hard to get right). Hence it seems better to let a compiler optimiser choose what is best. However, it might not realise that CxTYPE(cx) won't be changed, even as a side effect of any function called by this code. Hence hoist it into a constant variable to make this unequivocal.
| * B::Deparse now handles n-at-a-time for.Nicholas Clark2021-10-152-2/+23
| |
| * B::Concise now handles n-at-a-time for.Nicholas Clark2021-10-152-3/+134
| |
| * Regression tests and documentation for n-at-a-time for.Nicholas Clark2021-10-153-0/+400
| |
| * Implement n-at-a-time for loops.Nicholas Clark2021-10-155-1195/+1273
| | | | | | | | | | | | | | | | | | For example, this now works: for my ($key, $value) (%hash) { ... } Only for scalars declared with my as a list in the for loop statement. As many as you want (unless you want more than 4294967296).
| * Generate the optree for n-at-a-time for loops.Nicholas Clark2021-10-152-4/+68
| | | | | | | | | | | | Perl_newFOROP can now also take an OP_LIST corresponding to two or more lexicals to iterate over n-at-a-time, where those lexicals are all declared in the for statement, and occupy consecutive pad slots.
| * Iterate for loops $n-at-a-time in PP_ITER.Nicholas Clark2021-10-151-15/+77
| | | | | | | | | | This commit provides the runtime changes needed to iterate for loops over two or more variables.
| * Re-indent the case statement in pp_iter, ready for the next commit.Nicholas Clark2021-10-151-131/+129
| | | | | | | | | | | | | | Add braces and indent a block that will become a `for` loop in the next commit. With the exception of these and merging 3 opening braces onto the `if` or `else` on the previous lines, this commit is purely a whitespace change.
| * Tests for existing for loop optrees.Nicholas Clark2021-10-152-0/+187
|/
* GDBM_File: Implement crash-tolerance and export/import functions.Sergey Poznyakoff2021-10-146-58/+661
| | | | | | | | | | | | | | | | | * ext/GDBM_File/Makefile.PL: Register new constants: gdbm_open flags and return values for gdbm_latest_snapshot. * ext/GDBM_File/GDBM_File.pm: Update documentation. Export new constants. Raise version to 1.21. * ext/GDBM_File/GDBM_File.xs (dbcroak): Include system error infomation, when appropriate. (gdbm_syserrno): Return a meaningful value if not_here. (gdbm_dump, gdbm_load, gdbm_convert) (gdbm_failure_atomic, gdbm_latest_snapshot) (gdbm_crash_tolerance_status): New functions. * ext/GDBM_File/t/dump.t: New testcase. * ext/GDBM_File/t/snapshot.t: New testcase. * MANIFEST: List new files.
* Merge branch 'perlbug-string-3' into bleadJames E Keenan2021-10-133-8/+3
|\ | | | | | | | | For p.r. https://github.com/Perl/perl5/pull/19181; last of 3 pull requests for https://github.com/Perl/perl5/issues/19183
| * Send bugs to GitHubJames E Keenan2021-10-133-8/+3
|/ | | | | Do not advise sending mail to 'perlbug@perl.org', as that now simply triggers a response redirecting sender to GitHub.
* perlhacktips: Fix typoKarl Williamson2021-10-131-1/+1
|
* Add a section to INSTALL describing that we now rely on some C99Nicholas Clark2021-10-131-0/+37
| | | | | And the implications for XS authors writing code to work on both current and earlier perl installations.
* perldelta for C99 supportNicholas Clark2021-10-131-1/+12
|
View Lorry Controller Status