=head1 DESCRIPTION
This is a list of wishes for Perl. The most up to date version of this file
-is at L<http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/Porting/todo.pod>
+is at L<https://github.com/Perl/perl5/blob/blead/Porting/todo.pod>.
The tasks we think are smaller or easier are listed first. Anyone is welcome
to work on any of these, but it's a good idea to first contact
F<AUTHORS> file, which ships in the official distribution. How many other
programming languages offer you 1 line of immortality?
-=head1 Tasks that need only a little Perl knowledge
-
-=head2 Fix POD errors in Perl documentation
-
-Perl documentation is furnished in POD (Plain Old Documentation); see
-L<perlpod>. We also have a utility that checks for various errors in
-this documentation: F<t/porting/podcheck.t>. Unfortunately many files
-have errors in them, and there is a database of known problems, kept in
-F<t/porting/known_pod_issues.dat>. The most prevalent errors are lines
-too wide to fit in a standard terminal window, but there are more
-serious problems as well; and there are items listed there that are not
-in fact errors. The task would be to go through and clean up the
-documentation. This would be a good way to learn more about Perl.
-
=head1 Tasks that only need Perl knowledge
-=head2 Classify bug tickets by type
+=head2 Label bug tickets by type
-Known bugs in Perl are tracked by L<https://rt.perl.org/> (which also
-includes Perl 6). A summary can be found at
-L<https://rt.perl.org/NoAuth/perl5/Overview.html>.
-It shows bugs classified by "type". However, the type of many of the
-bugs is "unknown". This greatly lowers the chances of them getting
+Known bugs in Perl are tracked by L<https://github.com/Perl/perl5/issues>.
+It shows bugs and can be filtered by assigned labels. However, many are
+L<unlabeled|https://github.com/Perl/perl5/issues?q=is%3Aopen+is%3Aissue+no%3Alabel>
+or have the label L<"Needs Triage"|https://github.com/Perl/perl5/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+Triage%22>.
+This greatly lowers the chances of them getting
fixed, as the number of open bugs is overwhelming -- too many to wade
through for someone to try to find the bugs in the parts of
Perl that s/he knows well enough to try to fix. This task involves
-going through these bugs and classifying them into one or more types.
+going through these bugs and assigning one or more labels, and removing the
+"Needs Triage" label if present.
=head2 Ongoing: investigate new bug reports
the poster about it, asking for example code that reproduces the
problem. Such code should be added to the test suite as TODO tests, and
the ticket should be classified by type. To get started on this task,
-look at the tickets that are marked as "New Issues" in
-L<https://rt.perl.org/NoAuth/perl5/Overview.html>.
+look at the issues with no comments at
+L<https://github.com/Perl/perl5/issues?q=is%3Aopen+is%3Aissue+comments%3A0>.
=head2 Migrate t/ from custom TAP generation
quite a few tests in F<t/> have not been refactored to use it. Refactoring
any of these tests, one at a time, is a useful thing TODO.
-The subdirectories F<base>, F<cmd> and F<comp>, that contain the most
-basic tests, should be excluded from this task.
+The subdirectories F<base>, F<cmd>, F<comp> and F<opbasic>, that contain the
+most basic tests, should be excluded from this task.
=head2 Automate perldelta generation
the bug remains open because no one realizes that it has been fixed.
Ideally, every open bug should have a TODO test in the core test suite.
+=head2 deparse warnings nicely
+
+Currently Deparse punts on deparsing the bitmask for warnings, which it
+dumps uglily as-is. Try running this:
+
+ $ ./perl -Ilib -MO=Deparse -e 'use warnings "pipe"; die'
+
+Deparse.pm could use the package variables in warnings.pm that warnings.pm
+itself uses to convert the list passed to it into a bitfield. Deparse just
+needs to reverse that.
+
+=head2 test and fix Deparse with perl's test suite
+
+If you run perl's tests with the TEST_ARGS environment variable set to
+C<-deparse> (e.g., run C<TEST=-deparse make test>), each test file will be
+deparsed and the deparsed output will be run. Currently there are many
+failures, which ought to be fixed. There is in F<Porting/deparse-skips.txt>
+a list of tests known to fail, but it is out of date. Updating it would
+also help.
+
+This is an incremental task. Every small bit helps. It is also a task that
+may never end. As new tests are added, they tickle corner cases that
+B::Deparse cannot yet handle correctly.
+
+This task I<may> need a bit of perl guts knowledge. But what changes need
+to be made is usually easy to see by dumping op trees with B::Concise:
+
+ $ ./perl -Ilib -MO=Concise -e 'foo(); print @_; die $$_'
+
+and adjusting B::Deparse to handle whatever you see B::Concise produce.
+This is also a good way to I<learn> how perl's op trees work.
+
=head1 Tasks that need a little sysadmin-type knowledge
Or if you prefer, tasks that you would learn from, and broaden your skills
=item *
- cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
+ cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
=item *
On these systems, it might be the default compilation mode, and there
is currently no guarantee that passing no use64bitall option to the
Configure process will build a 32bit perl. Implementing -Duse32bit*
-options would be nice for perl 5.19.8.
+options would be nice for perl 5.33.1.
=head2 Profile Perl - am I hot or not?
One piece of Perl code that might make a good testbed is F<installman>.
-=head2 Improve win32/wince.c
-
-Currently, numerous functions look virtually, if not completely,
-identical in both F<win32/wince.c> and F<win32/win32.c> files, which can't
-be good.
-
=head2 Use secure CRT functions when building with VC8 on Win32
Visual C++ 2005 (VC++ 8.x) deprecated a number of CRT functions on the basis
Furthermore, POSIX::access() behaves differently for directories having the
read-only attribute set depending on what CRT library is being used. For
-example, the _access() function in the VC6 and VC7 CRTs (wrongly) claim that
+example, the _access() function in the VC7 CRT (wrongly) claims that
such directories are not writable, whereas in fact all directories are writable
unless access is denied by DACLs. (In the case of directories, the read-only
attribute actually only means that the directory cannot be deleted.) This CRT
been written so that it reflects the state of the read-only attribute, even
for directories (whatever CRT is being used), for symmetry with chmod().)
-=head2 strcat(), strcpy(), strncat(), strncpy(), sprintf(), vsprintf()
-
-Maybe create a utility that checks after each libperl.a creation that
-none of the above (nor sprintf(), vsprintf(), or *SHUDDER* gets())
-ever creep back to libperl.a.
-
- nm libperl.a | ./miniperl -alne '$o = $F[0] if /:$/;
- print "$o $F[1]" if $F[0] eq "U" && $F[1] =~ /^(?:strn?c(?:at|py)|v?sprintf|gets)$/'
-
-Note, of course, that this will only tell whether B<your> platform
-is using those naughty interfaces.
-
-=head2 -D_FORTIFY_SOURCE=2
-
-Recent glibcs support C<-D_FORTIFY_SOURCE=2> which gives
-protection against various kinds of buffer overflow problems.
-It should probably be used for compiling Perl whenever available,
-Configure and/or hints files should be adjusted to probe for the
-availability of these feature and enable it as appropriate.
-
=head2 Arenas for GPs? For MAGIC?
C<struct gp> and C<struct magic> are both currently allocated by C<malloc>.
progressively update ExtUtils::ParseXS to generate OP implementations for
some XSUBs.
+=head2 Document how XS modules can install lexical subs
+
+There is an example in XS::APItest (look for C<lexical_import> in
+F<ext/XS-APItest/APItest.xs>). The documentation could be based on it.
+
=head2 Remove the use of SVs as temporaries in dump.c
F<dump.c> contains debugging routines to dump out the contains of perl data
system() accepts a LIST syntax (and a PROGRAM LIST syntax) to avoid
running a shell. readpipe() (the function behind qx//) could be similarly
-extended.
+extended. Note that changing readpipe() itself may not be the solution, as
+it currently has unary precedence, and allowing a list would change the
+precedence.
=head2 Audit the code for destruction ordering assumptions
Change 25773 notes
- /* Need to check SvMAGICAL, as during global destruction it may be that
- AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
- is now part of the linked list of SV heads, rather than pointing to
- the original body. */
- /* FIXME - audit the code for other bugs like this one. */
+ /* Need to check SvMAGICAL, as during global destruction it may be that
+ AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
+ is now part of the linked list of SV heads, rather than pointing to
+ the original body. */
+ /* FIXME - audit the code for other bugs like this one. */
adding the C<SvMAGICAL> check to
have catgets().
For the really pure at heart, consider extending this item to cover
-also the warning messages (see L<perllexwarn>, C<warnings.pl>).
+also the warning messages (see L<warnings>, F<regen/warnings.pl>).
=head1 Tasks that need a knowledge of the interpreter
These tasks would need C knowledge, and knowledge of how the interpreter works,
or a willingness to learn.
+=head2 fix refaliasing with nested and recursive subroutines
+
+Currently aliasing lexical variables via reference only applies to the
+current subroutine, and does not propagate to inner closures, nor does
+aliasing of outer variables within closures propagate to the outer
+subroutine. This is because each subroutine has its own lexical pad and the
+aliasing works by changing which SV the pad points to.
+
+One possible way to fix this would be to create new ops for accessing
+variables that are closed over. So C<my $x; sub {$x}> would use a new op
+type, say C<padoutsv>, instead of the C<padsv> currently used in the
+sub. That new op would possibly check a flag or some such and see if it
+needs to fetch the variable from an outer pad. If we follow this approach,
+it should be possible at compile time to detect cases where the more
+complex C<padoutsv> op is unnecessary and revert back to the simpler,
+faster C<padsv>. There would need to be corresponding ops for arrays,
+hashes, and subs, too.
+
+There is also a related issue with recursion and C<state> variables. A
+subroutine actually has a list of lexical pads, each one used at a
+different recursion level. If a C<state> variable is aliased to another
+variable after a recursive call to the same subroutine, that higher call
+depth will not see the effect of aliasing, because the second pad will have
+been created already. Similarly, aliasing a state variable within a
+recursive call will not affect outer calls, even though all call depths are
+supposed to share the same C<state> variables.
+
+Both of these bugs affect C<foreach> aliasing, too.
+
=head2 forbid labels with keyword names
Currently C<goto keyword> "computes" the label value:
=head2 truncate() prototype
The prototype of truncate() is currently C<$$>. It should probably
-be C<*$> instead. (This is changed in F<opcode.pl>)
+be C<*$> instead. (This is changed in F<regen/opcodes>.)
=head2 error reporting of [$a ; $b]
=head2 strict as warnings
-See L<http://markmail.org/message/vbrupaslr3bybmvk>, where Josua ben Jore
+See L<http://markmail.org/message/vbrupaslr3bybmvk>, where Joshua ben Jore
writes: I've been of the opinion that everything strict.pm does ought to be
able to considered just warnings that have been promoted to 'FATAL'.
warnings. An unworked RT ticket (#5087) has been open for almost seven
years for this discrepancy.
-=head2 UTF-8 revamp
-
-The handling of Unicode is unclean in many places. In the regex engine
-there are especially many problems. The swash data structure could be
-replaced my something better. Inversion lists and maps are likely
-candidates. The whole Unicode database could be placed in-core for a
-huge speed-up. Only minimal work was done on the optimizer when utf8
-was added, with the result that the synthetic start class often will
-fail to narrow down the possible choices when given non-Latin1 input.
-Karl Williamson has been working on this - talk to him.
-
=head2 state variable initialization in list context
Currently this is illegal:
state ($a, $b) = foo();
-In Perl 6, C<state ($a) = foo();> and C<(state $a) = foo();> have different
+In Raku, C<state ($a) = foo();> and C<(state $a) = foo();> have different
semantics, which is tricky to implement in Perl 5 as currently they produce
-the same opcode trees. The Perl 6 design is firm, so it would be good to
+the same opcode trees. The Raku design is firm, so it would be good to
implement the necessary code in Perl 5. There are comments in
C<Perl_newASSIGNOP()> that show the code paths taken by various assignment
constructions involving state variables.
debugger on a running Perl program, although I'm not sure how it would be
done." ssh and screen do this with named pipes in /tmp. Maybe we can too.
-=head2 LVALUE functions for lists
-
-The old perltodo notes that lvalue functions don't work for list or hash
-slices. This would be good to fix.
-
=head2 regexp optimizer optional
The regexp optimizer is not optional. It should be configurable to be optional
This would allow proposals such as short circuiting sort to be implemented
as a module on CPAN.
-=head2 lexical aliases
-
-Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>).
-
=head2 Self-ties
Self-ties are currently illegal because they caused too many segfaults. Maybe
=head2 Virtualize operating system access
Implement a set of "vtables" that virtualizes operating system access
-(open(), mkdir(), unlink(), readdir(), getenv(), etc.) At the very
-least these interfaces should take SVs as "name" arguments instead of
-bare char pointers; probably the most flexible and extensible way
-would be for the Perl-facing interfaces to accept HVs. The system
-needs to be per-operating-system and per-file-system
-hookable/filterable, preferably both from XS and Perl level
-(L<perlport/"Files and Filesystems"> is good reading at this point,
-in fact, all of L<perlport> is.)
+(chdir(), chmod(), dbmopen(), getenv(), glob(), link(), mkdir(), open(),
+opendir(), readdir(), rename(), rmdir(), stat(), sysopen(), uname(),
+unlink(), etc.). At the very least these interfaces should take SVs as
+"name" arguments instead of bare char pointers; probably the most
+flexible and extensible way would be for the Perl-facing interfaces to
+accept HVs. The system needs to be per-operating-system and
+per-file-system hookable/filterable, preferably both from XS and Perl
+level (L<perlport/"Files and Filesystems"> is good reading at this
+point, in fact, all of L<perlport> is.)
This has actually already been implemented (but only for Win32),
take a look at F<iperlsys.h> and F<win32/perlhost.h>. While all Win32
=head2 repack the optree
+B<Note:> This entry was written in reference to the I<old> slab allocator,
+removed in commit 7aef8e5bd14.
+
Repacking the optree after execution order is determined could allow
removal of NULL ops, and optimal ordering of OPs with respect to cache-line
filling. I think that
would produce this output
- Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
- Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
(rather than lines 4 and 5), but this would seem to require every OP to carry
(at least) line number information.
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
-of 5.19.8"
+of 5.33.1"
=head2 make ithreads more robust
https://perl5.git.perl.org / perl5.git / blobdiff