summaryrefslogtreecommitdiff
path: root/op.c
Commit message (Collapse)AuthorAgeFilesLines
* Enable warnings on «use v5.35»Leon Timmermans2021-08-151-0/+3
|
* Remove the flags OPpSORT_STABLE and OPpSORT_UNSTABLE.Nicholas Clark2021-07-311-13/+0
| | | | | | Remove the code in Perl_ck_sort() that reads from PL_hintgv that sets these, and the code in pp_sort that reads them and sets SORTf_STABLE and SORTf_UNSTABLE (which were no longer read. Remove these too.)
* Where the key is an SV, replace some hv_* calls with hv_*_ent equivalents.Nicholas Clark2021-07-261-6/+4
| | | | | This avoids the SvUTF8(tmpstr) ? -(I32)SvCUR(tmpstr) : (I32)SvCUR(tmpstr) code dance.
* op.c: Remove leading tabKarl Williamson2021-07-251-1/+1
| | | | | This was the only remaining, non-generated base-level leading tab, and so resolves GH #18792
* warn when using each on an anonymous hash or arrayTony Cook2021-07-061-1/+67
| | | | | | | We've had three tickets over the years where the user has been confused by the behaviour of each on an anonymous array or hash, there's no way to tell if other users have been struck by the same issue, so make it easier to diagnose by producing a warning.
* scalarseq() should not put an OP_ENTER kid into scalar context (fixes #18855)Paul "LeoNerd" Evans2021-06-171-2/+7
|
* Rename scalarseq() to a somewhat more meaningful voidnonfinal()Paul "LeoNerd" Evans2021-06-161-7/+8
|
* replace all instances of PERL_IMPLICIT_CONTEXT with MULTIPLICITYTomasz Konojacki2021-06-091-2/+2
| | | | | | | | | | | | Since the removal of PERL_OBJECT (acfe0abcedaf592fb4b9cb69ce3468308ae99d91) PERL_IMPLICIT_CONTEXT and MULTIPLICITY have been synonymous and they're being used interchangeably. To simplify the code, this commit replaces all instances of PERL_IMPLICIT_CONTEXT with MULTIPLICITY. PERL_IMPLICIT_CONTEXT will stay defined for compatibility with XS modules.
* Rename G_ARRAY to G_LIST; provide back-compat when not(PERL_CORE)Paul "LeoNerd" Evans2021-06-021-4/+4
|
* Base *.[ch] files: Replace leading tabs with blanksMichael G Schwern2021-05-311-4633/+4633
| | | | | | | This is a rebasing by @khw of part of GH #18792, which I needed to get in now to proceed with other commits. It also strips trailing white space from the affected files.
* Make scalar assignment to undef a compile time errorRichard Leach2021-05-251-0/+2
|
* OP_ENTERTRY no longer needs to handle OPf_SPECIAL flagPaul "LeoNerd" Evans2021-02-141-3/+0
|
* A totally new optree structure for try/catch involving three new optypesPaul "LeoNerd" Evans2021-02-141-11/+90
|
* Add a newTRYCATCHOP(); migrate the custom code out of perly.y into itPaul "LeoNerd" Evans2021-02-141-0/+42
|
* Avoid read-after-free of o->op_flags in Perl_ck_eval()Paul "LeoNerd" Evans2021-02-091-1/+2
|
* Initial attempt at feature 'try'Paul "LeoNerd" Evans2021-02-041-0/+2
| | | | | | | | | * Add feature, experimental warning, keyword * Basic parsing * Basic implementation as optree fragment See also https://github.com/Perl/perl5/issues/18504
* Update comment after 5b354d2a8aHugo van der Sanden2021-01-051-1/+1
| | | | | The specified commit fixed a bug by treating ($x, undef) on the LHS as 2 scalars; this comment should have been updated to match.
* add a bareword_filehandles feature, which is enabled by defaultTony Cook2021-01-041-0/+23
| | | | This disables use of bareword filehandles except for the built-in handles
* op.c: croak on "my $_" when "use utf8" is in effectTomasz Konojacki2020-12-301-7/+9
| | | | Fixes #18449
* skip trying to constant fold an incomplete op treeTony Cook2020-12-231-1/+1
| | | | | | | | | | | | | | | This code would try to constant fold an op tree like relop +- null +- constant which would underflow the stack, potentially crashing perl. This is intended as a quick fix rather than as a complete solution. Fixes #18380
* Remove empty "#ifdef"sTom Hukins2020-12-081-4/+0
|
* Fix unitialized warnings in S_pmtransNicolas R2020-11-061-1/+1
|
* autodoc.pl: Enhance apidoc_section featureKarl Williamson2020-11-061-9/+9
| | | | | | | | | | | This feature allows documentation destined for perlapi or perlintern to be split into sections of related functions, no matter where the documentation source is. Prior to this commit the line had to contain the exact text of the title of the section. Now it can be a $variable name that autodoc.pl expands to the title. It still has to be an exact match for the variable in autodoc, but now, the expanded text can be changed in autodoc alone, without other files needing to be updated at the same time.
* Perl_custom_op_get_field(): remove undef behaviourDavid Mitchell2020-10-301-8/+6
| | | | | | | | | | | | | | | | | | | Thus function has a couple a switches with default: NOT_REACHED; /* NOTREACHED */ but clang is complaining that the value returned by the function is undefined if those default branches are taken, since the 'any' variable doesn't get set in that path. Replace the NOTREACHED with a croak("panic: ..."). It's possible (albeit not intended) for Perl_custom_op_get_field() to be called with a 'field' arg which triggers the default case. So if this ever happens, make it clear that something has gone wrong, rather than just silently continuing on non-debugging builds. In any case, this shuts up clang.
* Document newSUB, newATTRSUBKarl Williamson2020-10-061-0/+11
|
* Document vload_moduleKarl Williamson2020-09-051-0/+3
|
* perlapi: capitalize 'op'Karl Williamson2020-09-051-1/+1
|
* Reorganize perlapiKarl Williamson2020-09-041-1/+1
| | | | | This uses a new organization of sections that I came up with. I asked for comments on p5p, but there were none.
* Change some =head1 to apidoc_section linesKarl Williamson2020-09-041-8/+8
| | | | | apidoc_section is slightly favored over head1, as it is known only to autodoc, and can't be confused with real pod.
* Document a bunch of foo_nocontext functionsKarl Williamson2020-08-231-0/+5
| | | | These just refer to foo's pod, with an explanation of 'nocontext'
* Use av_top_index() instead of av_tindex()Karl Williamson2020-08-191-1/+1
| | | | | | | I was never happy with this short form, and other people weren't either. Now that most things are better expressed in terms of av_count, convert the few remaining items that are clearer when referring to an index into using the fully spelled out form
* list assign in list context was over-optimisingDavid Mitchell2020-08-111-3/+7
| | | | | | | | | | | | | | | | | | | GH #17816 This code: my $x = 1; print (($x, undef) = (2 => $x)); was printing "22" when it should have been printing "21". An optimisation skips the 'common values on both sides' test when the LHS of an assign only contains a single var; as the example above shows, this is not sufficient. This was broken by v5.23.1-202-g808ce55782 This commit fixes it by counting undef's on the LHS towards the var count if they don't appear first.
* add a default enabled feature "multidimensional"Tony Cook2020-08-101-3/+11
| | | | | | Like "indirect" this feature is enabled by default and enables the perl4 hash-based multidimensional array emulation documented under $; in perlvar.
* re-work opslab handling to avoid non-portable alignment assumptionsTony Cook2020-07-301-40/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #17871 The op slab allocator code made the assumption that since OP and hence OPSLOT contain pointers, the base of each of those would be an integral number of sizeof(pointer) (pointer units) from the beginning of OPSLAB. This assumption is non-portable, and broke calculating the location of the slab based on the address of the op slot and the op slot offset on m68k platforms. To avoid that, this change now stores the opslot_offset as the offset in pointer units from the beginning of opslab_slots rather than from the beginning of the slab. If alignment on a pointer boundary for OPs is required, the compiler will align opslab_opslots and since we work in pointer units from there, any allocated op slots will also be aligned. If we assume PADOFFSET is no larger than a pointer and requires no stricter alignment and structures in themselves have no stricter alignment requirements then since we work in pointer units all core OP structures should have sufficient alignment (if this isn't true, then it's not a new problem, and not the problem I'm trying to solve here.) I haven't been able to test this on m68k hardware (the emulator I tried to use can't maintain a network connection.)
* Remove use of dVAR in coreDagfinn Ilmari Mannsåker2020-07-201-60/+0
| | | | | It only does anything under PERL_GLOBAL_STRUCT, which is gone. Keep the dNOOP defintion for CPAN back-compat
* Fix tr/// determination of inplace editing for EBCDICKarl Williamson2020-05-271-20/+38
| | | | | | | | | | | I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Since we didn't have an EBCDIC smoker at the time, I couldn't be sure that the fix actually worked. Now that we do have a smoker, I have successfully tested it. This patch is constructed so that the code generated on non-EBCDIC platforms should not be changed by it.
* Fix a bunch of repeated-word typosDagfinn Ilmari Mannsåker2020-05-221-8/+6
| | | | | Mostly in comments and docs, but some in diagnostic messages and one case of 'or die die'.
* Revert "avoid identical stack traces"David Mitchell2020-04-271-23/+1
| | | | This reverts commit f2f32cd638746f538da6db804dab6dd54e654f30.
* Revert "fixup to "avoid identical stack traces" - try 2"David Mitchell2020-04-271-3/+4
| | | | This reverts commit ad89278aa25475fb03971aec66692e18e35d9c07.
* op.c: Add, clarify commentsKarl Williamson2020-04-021-30/+48
|
* tr/abc/de/: Properly handle longer lhs in in-place calcKarl Williamson2020-04-021-1/+6
| | | | | | | | | | | | | | | | | | | | | | A tr/// can be done in-place if the target string doesn't contain a character whose transliterated representation is longer than the original. Otherwise, writing the new value would destroy the next character we need to read. In general, we can't know if a particular string contains such a character without keeping a list of the problematic characters, and scanning it ahead of time for occurrences of those. Instead, we determine at compilation time if, for a given transliteration, if there exists any possible target string that could have an overwriting problem. If none exist, we edit in place. Otherwise, we first make a copy. Prior to this commit, the code failed to account for the case where the rhs is shorter than the left, so that any unmatched lhs characters map to the final rhs one. The reason the code didn't consider this is that I didn't think of this possibility when writing it. This fixes #17654 and #17643
* fix PERL_GLOBAL_STRUCT_PRIVATE buildsDavid Mitchell2020-03-201-0/+4
| | | | | Sprinkle some dVAR pixie dust to fix recent bitrot on that build configuration.
* fixup to "avoid identical stack traces" - try 2David Mitchell2020-03-181-4/+3
| | | | | | | | | | | | | | | | | | | GH #15109, #17567 [ this commit was originally applied as v5.31.9-121-gfb8188b84d, but was quickly reverted by v5.31.9-124-g6311900a66. I'm now -re-applying it, but with a 'SAVEFREEOP(PL_curcop)' added, which was missing from the original commit. ] My original fix for this issue, v5.31.6-141-gf2f32cd638 made a shallow copy of &PL_compiling. However, for non-default warning bits, this made two COPs share the malloced() cop_warnings, and bad things ensured. In particular this was flagged up in: GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz" The fix in this commit is to do a deep copy of the COP using newSTATEOP().
* op.c: change Optype to I32 for cmpchain functionsYves Orton2020-03-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Optype appears to be almost completely unused, and on Win32 builds we saw warnings from the cmpchain patches: perly.y(1063) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1065) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1079) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1081) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data Reviewing the code I noticed that functions like Perl_newBINOP() have an I32 type argument, and functions like OpTYPE_set() coerce such arguments into type OPCODE: #define OpTYPE_set(o,type) \ STMT_START { \ o->op_type = (OPCODE)type; \ o->op_ppaddr = PL_ppaddr[type]; \ } STMT_END this patch changes the signature to the new cmpchain functions so that they do they same, and change the type for storage for op_type values to also use OPCODE like most of the other op.c code.
* chained comparisonsZefram2020-03-121-0/+115
|
* Revert "fixup to "avoid identical stack traces""Nicolas R2020-03-121-2/+4
| | | | | | | | | | | | | | This reverts commit fb8188b84d8a8f34f90aa9a8d9837892967f6b93. Unfortunately this is causing some errors during global destruction like: Unbalanced string table refcount: (1) for "open_IN" during global destruction It seems to be flapping, and recompiling Perl could see or not the issue. Upstream-URL: https://github.com/Perl/perl5/commit/fb8188b84d8a8f34f90aa9a8d9837892967f6b93
* fixup to "avoid identical stack traces"David Mitchell2020-03-121-4/+2
| | | | | | | | | | | | | | GH #15109, #17567 My original fix for this issue, v5.31.6-141-gf2f32cd638 made a shallow copy of &PL_compiling. However, for non-default warning bits, this made two COPs share the malloced() cop_warnings, and bad things ensured. In particular this was flagged up in: GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz" The fix in this commit is to do a deep copy of the COP using newSTATEOP().
* op.c: S_fold_constants_eval can't be inlinedKarl Williamson2020-03-111-2/+3
| | | | Because it uses setjmp, is what g++ says
* make freed op re-use closer to O(1)Tony Cook2020-03-021-20/+59
| | | | | | | | | | | | | | | | previously freed ops were stored as one singly linked list, and a failed search for a free op to re-use could potentially search that entire list, making freed op lookups O(number of freed ops), or given that the number of freed ops is roughly proportional to program size, making the total cost of freed op handling roughly O((program size)**2). This was bad. This change makes opslab_freed into an array of linked list heads, one per op size. Since in a practical sense the number of op sizes should remain small, and insertion is amortized O(1), this makes freed op management now roughly O(program size). fixes #17555
* multiconcat: keep assign for 'local $foo = "..."'David Mitchell2020-02-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In something like local $~ = "$~X"; i.e. where localising a magic variable whose previous value should be used as part of a string concat on the RHS, don't fold the assign into the multiconcat op. Otherwise the code execution path looks a bit like: local($~) = undef; multiconcat($~, $~, "X"); [ where multiconcat's args are (target, arg1, arg2,....) ] and thus multiconcat sees an undef arg. By leaving the assign out of the multiconcat, code execution now looks like my $targ; multiconcat($targ, $~, "X"); local($~) = $targ; See http://nntp.perl.org/group/perl.perl5.porters/256898, "Bug in format introduced in 5.27.6". Although the bug only appears with magic vars, this patch pessimises all forms of 'local $foo = "..."', 'local $foo{bar} = "..."' etc. Strictly speaking the bug occurs because with 'local' you end up with two SVs (the saved one and the one currently in the glob) which both have the same container magic and where mg_set()ing one changes the mg_get() value of the other. Thus, vars like $!. One of the two SVs becomes an arg of multiconcat, the other becomes its target. Part of localising the target SV (before multiconcat is called) wipes the value of the arg SV.
View Lorry Controller Status