summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Split NAME line on multiple whitespacesJames E Keenan2018-11-231-1/+1
| | | | | | | | | | | | | For: RT # 133683 pod/perlmodlib.pod is a file generated by pod/perlmodlib.PL, which is run by 'miniperl' during 'make'. That program parses the 'NAME' header of .pod files and fragments of POD found in 'regen/opcode.pl'. The POD for B::Op_private is one such fragment. Correcting a superfluous whitespace in that fragment did not suffice to prevent the downstream formatting error reported in the RT -- an error visible with 'pod2text' and 'pod2html' as well. We also had to make the regex which perlmodlib.PL uses to parse the 'NAME' header more flexible.
* Bump the perl version in various places for 5.29.6Karen Etheridge2018-11-201-1/+1
|
* Bump the Perl version for 5.29.5Aaron Crane2018-10-201-1/+1
|
* Fatalize use of $* and $#James E Keenan2018-10-171-5/+0
| | | | | | | | Adapt tests in various files to removal of these variables. Add t/lib/croak/gv to test fatalizations of $# and $* -- tests therein adapted from tests formerly in t/lib/warnings/gv. Per: RT # 133583
* (perl #126760) adapt sigtrap for layers on STDERR.Tony Cook2018-10-101-9/+47
| | | | | | | | | | | | | | | | | | | sigtrap defines a signal handler apparently intended to be called under unsafe signals, since a) the code was written before safe signals were implemented and b) it uses syswrite() for output and avoid creating new SVs where it can. Unfortunately syswrite() doesn't handle PerlIO layers, *and* with syswrite() being disallowed for :utf8 handlers, throws an exception. This causes the sigtrap tests to fail if PERL_UNICODE is set and the current locale is a UTF-8 locale. I want to avoid allocating new SVs until the point where the code originally did so, so the code now attempts a syswrite() under eval, falling back to print, and then at the point where the original code started allocating SVs uses PerlIO::get_layers() to check if any layers might make a difference to the output.
* (perl #125760) fatalize sysread/syswrite/recv/send on :utf8 handlesTony Cook2018-10-101-121/+1
| | | | | | | | | | | | | This includes removing the :utf8 logic from pp_syswrite. pp_sysread retains it, since it's also used for read(). Tests that are specifically testing the behaviour against :utf8 handles have been removed (eg in lib/open.t), several other tests that incidentally used those functions on :utf8 handles have been adapted to use :raw handles instead (eg. op/readline.t). Test lib/sigtrap.t fails if STDERR is :utf8, in code from the original 5.000 commit, which is intended to run in a signal handler
* fix typosAlexandr Savca2018-10-095-9/+9
| | | | | | | | Committer: For porting tests: Update $VERSION in 4 files. Run: ./perl -Ilib regen/mk_invlists.pl ./perl -Ilib regen/regcharclass.pl
* Remove arybase support from B::DeparseDagfinn Ilmari Mannsåker2018-09-261-26/+5
|
* Remove support for setting $[ to a non-zero valueDagfinn Ilmari Mannsåker2018-09-262-14/+18
| | | | This removes arybase and all its surrounding machinery.
* (perl #130674) don't modify $^H in vars.pmTony Cook2018-09-262-3/+10
| | | | This could remove non-vars strictness from the caller.
* Remove B::Debug from core distribution.James E Keenan2018-09-251-1/+0
| | | | | | | | | | It continues to exist as a CPAN distribution. Increment $B::Terse::VERSION and $B::Concise::VERSION due to changes in POD. Remove internal links to B::Debug within two .pod files. For: RT #130410
* bumping versions to 5.29.4John SJ Anderson2018-09-201-1/+1
|
* There is no getpw() function in User::grent.James E Keenan2018-09-031-3/+3
| | | | | | | | | Documentation should refer to getgr(), per report from Elizabeth Mattijsen. Increment $VERSION. For: RT 133217
* Remove superfluous variable $gr_mem.James E Keenan2018-09-031-2/+2
| | | | | | Per recommendation by Elizabeth Mattijsen. For: RT 133217
* Correct typo reported by Elizabeth MattijsenJames E Keenan2018-09-031-1/+1
| | | | For: RT 133217
* Bump the perl version in various places for 5.29.3Chris 'BinGOs' Williams2018-08-201-1/+1
|
* mktables: Handle platforms with 3 digit exponentsKarl Williamson2018-08-201-0/+5
| | | | | | | C99 says there shouldn't be more than 2 digits in an exponent unless needed. But Windows uses three. This messes some stuff up that is expecting two. Change to remove leading zeros so that only two digits are used. This allows mktables to properly operate on Windows.
* lib/locale.t - no longer special case quadmath buildssisyphus2018-08-091-36/+11
| | | | The previous commit now has these respect locale
* mktables: Some tests are invalidKarl Williamson2018-08-031-0/+5
| | | | | These tests have been wrongly passing. A future commit will change that.
* lib/warnings.pm: Bump version to 1.43Karl Williamson2018-07-221-1/+1
|
* lib/Config/Extensions.pm: Bump version to .03Karl Williamson2018-07-221-1/+1
|
* Ensure perlmodlib.pod contains all non-dual-life modulesAaron Crane2018-07-222-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The pod/perlmodlib.pod file is generated at build time by pod/perlmodlib.PL, which looks at the POD of library and pragma files to find "=head1 NAME" directives. It reads each file a paragraph at a time ($/ = ""), and considers each individual paragraph as potentially containing POD. However, if it finds no "=head1 NAME" entry in a module, it silently ignores it. That's reasonable for dual-life modules — there's often a good reason why a particular file has no POD — but for single-life modules, this could well indicate an issue. In particular, commit effd17dc012719d584aa712c6c7bd5dc142885b6, as part of rearranging the contents of lib/warnings.pm, inadvertently changed the context of its "=head1 NAME" line so that it's no longer the start of a paragraph. This had the effect of removing warnings.pm from perlmodlib; that gap was pointed out by pink_mist++ on IRC. The fix for that is trivial: add a blank in the appropriate place in regen/warnings.pl, and regen. The change to pod/perlmodlib.PL to die on missing "=head1 NAME" lines has also yielded a second module (Config::Extensions) that was missing from perlmodlib for the same reason; that's also fixed in this commit.
* Use Unicode 11.0Unicode Consortium2018-07-2056-2670/+6605
| | | | This completes the process of upgrading to Unicode 11.0.
* Prepare for Unicode 11.0Karl Williamson2018-07-201-7/+81
| | | | | | | | | Unicode 11 has some new data files needed for it, and some changes in the boundary rules that need to be accounted for. This does all that can be done without causing tests to fail. The LB algorithm has changed, and tests would fail if we included the code changes needed for that change in this commit. Instead those few lines will come as part of the Unicode 11.0 commit.
* mktables: Comment, white-spaceKarl Williamson2018-07-201-2/+1
|
* mktables: Avoid some unnecessary workKarl Williamson2018-07-201-17/+1
| | | | | By simply removing a special case, we can avoid having to work around it later.
* mktables: Improve warning messageKarl Williamson2018-07-201-1/+1
| | | | | | | I forgot that mktables (until told that things have been updated) makes all failing boundary condition tests pass and hence I got confused. It's a simple matter to remind the user that this is happening, to prevent the confusion
* Bump version to 5.29.2Steve Hay2018-07-201-1/+1
| | | | (including regen\opcode.pl)
* regen opcodes for 5.29.1Sawyer X2018-06-271-1/+1
|
* mktables: Correct L<> for perluniprops; rmv trail spaceKarl Williamson2018-06-251-2/+2
|
* mktables: Add, change some commentsKarl Williamson2018-06-251-4/+7
|
* mktables: Handle cjkiicore properlyKarl Williamson2018-06-251-1/+1
| | | | | | | This property is not normally compiled by perl, but an installation may choose to use it. It was failing some tests because this is a special property that is like a perl dual-var. It is both binary, and non-binary, and commit 346f9bfbe12 forgot that.
* mktables: Add guard against Unicode breakageKarl Williamson2018-06-251-0/+8
| | | | | | | This adds a check that a new Unicode version doesn't create a rational number that is too close to a current rational for our existing floating point precision. Should this happen, we can increase the precision we use.
* Add tests for qr/\p{}/Karl Williamson2018-06-251-1/+11
| | | | This adds tests for nv=integer, where 'integer' is expressed in %e.
* utf8.c: Handle qr!\p{nv=6/8}!Karl Williamson2018-06-251-2/+14
| | | | | | | | I thought this worked before, but it turns out it never did. This commit allows the rational number specified in looking up the Numeric Value property to not be in lowest possible terms. Unicode even furnishes some of its data in non-lowest form, so we should accept this.
* Revise \p{nv=float} lookupKarl Williamson2018-06-252-181/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Numeric Value property allows one to find all code points that have a certain numeric value. An example would be to match against any character in any of the world's scripts which is effectively equivalent to the digit zero. It is documented that we accept either integers (like \p{nv=9}) or rationals (like \p{nv=1/2}). But we also accept floating point representations in case a conversion to numeric has happened. I think it is right that we not document these and their vagaries. One reason is that Unicode might someday create a new rational number that, to the precision we currently accept, is indistinguishable from an existing one, so that we would have to increase the precision. But there was a bug I introduced years ago. I thought that in order for a float to be considered to match a close rational, that 3 significant digits of precision would be needed, like .667 to match 2/3. That still seems reasonable. But I didn't implement that concept. Instead, prior to this commit, it was 3 (not necessarily significant) digits, so that for 1/160, it would match .001. This commit corrects that, and makes the lookup simpler. mktables will use sprintf %e to get the number normalized and having the 3 signicant digits required. At runtime, a floating number is normalized using the same format, and the result looked up in a hash. This eliminates the need to worry about matching within some epsilon. Further simplifications in utf8_heavy.pl are achieved by making a more precise definition as to what an acceptable number looks like, so we don't have to check later to see if what matched really was one.
* Remove support for qr/\p{_CanonDCIJ}Karl Williamson2018-06-251-27/+0
| | | | | | | This is the third and final obsolete property that is being removed in 3 sequential commits. The property is not used in cpan, and is being removed as part of the cleanup instigated because another of the 3 would require extra code to handle if we were to keep it around.
* Remove support for qr/\p{_Comb_Above}/Karl Williamson2018-06-251-7/+0
| | | | | | | | | | | | This property is no longer used in the core, nor in cpan, and is marked as for core use only, not necessarily stable. I have kept it around because it was work to remove it, but now the revamping of the property lookup scheme was causing failures with a similar property, and the previous commit removed that one. There are just three of these properties, and I think it's time to remove support for all three. The next commit will do the same for the third one.
* Remove qr/\p{_Case_Ignorable}/Karl Williamson2018-06-251-50/+0
| | | | | | | | | | This property is no longer used in the core, nor in cpan, and is marked as for core use only, not necessarily stable. I have kept it around because it was work to remove it, but now the revamping of the property lookup scheme was causing failures with it, when compiling on early Unicode releases. That could be fixed with extra work, but simply removing it also fixes the problem and avoids future maintenance costs.
* qr/\p{...}/: Rmv redundant text from warning msg detailKarl Williamson2018-06-251-2/+2
| | | | | | | This text is emitted when compiling a pattern using a deprecated property. The text is added detail to the main text of the message (which isn't changing), and is redundant because it just says it's deprecated, and the main message already says that.
* Unicode::UCD: Avoid uninit messageKarl Williamson2018-06-251-9/+12
| | | | | I found a case where this array can be empty, so add a test for that to avoid trying to look at the first (non-existent) element.
* Bump version to 5.29.0 and regenerate everythingSawyer X2018-06-242-2/+8
|
* lib/locale.t: TODO some locales on SolarisKarl Williamson2018-05-011-0/+5
| | | | | | There is a bug in Solaris with locales which have a multi-byte decimal radix character. Make these TODO, like we do cygwin, which has had a similar problem.
* lib/locale.t: Mark a test problematicKarl Williamson2018-05-011-0/+1
| | | | | | | We now have found a system that fails this test. Tests that are listed as problematic automatically get marked as TODO when they fail with specified platforms. The next commit will specify the platform that this is fails on.
* Fix Module::CoreList versionsSawyer X2018-04-201-1/+1
|
* Document that `use v5.12` and `use feature ":5.12"` differAaron Crane2018-04-201-1/+4
|
* RT#132744: clarify subs/vars documentationAaron Crane2018-04-192-12/+14
| | | | | | | | | | That ticket points out that subs.pm mentions using declared sub names "without parentheses". That is indeed misleading; using the term "list operators" would be better. While changing that, I've also tweaked the wording about lexical scopes and the inability to rescind these declarations, and ensured that the vars.pm has the same revised text.
* mktables: Add tests for t/re/unipropsFOOKarl Williamson2018-04-171-0/+18
| | | | | | Make sure that a non-binary property doesn't get mistakenly matched in \p{}, which is only for binary ones. There are some ambiguities that this test keeps us from falling victim to.
* bytes.pm: remove 'use utf8' from exampleDavid Mitchell2018-04-041-3/+1
| | | | | | It's not needed. RT #125619
* mktables: Add aliases to the Present_In propertyKarl Williamson2018-03-201-0/+3
| | | | | | This property parallels the Age property (but is cumulative). Each table in it should have the same property value possibilities as the corresponding Age table.
View Lorry Controller Status