This issue has to do with the --weld-nested-containers option in the specific case of formatting a function which returns a list of anonymous subs. For example
$promises[$i]->then(
sub { $all->resolve(@_); () },
sub {
$results->[$i] = [@_];
$all->reject(@$results) if --$remaining <= 0;
return ();
}
);A bug introduced in v20201202 caused an incorrect welding to occur when the -wn flag was set
$promises[$i]->then( sub { $all->resolve(@_); () },
sub {
$results->[$i] = [@_];
$all->reject(@$results) if --$remaining <= 0;
return ();
} );This bug has been fixed, and code which has been incorrectly formatted will be correctly formatted with the next release. The bug was a result of a new coding introduced in v20201202 for fixing some issues with parsing sub signatures. Previously they were sometimes parsed the same as prototypes and sometimes as lists, now they are always parsed as lists.
Testing revealed that for a line such as
package Bob::Dog;which has extra spaces or even tabs after the keyword 'package', the extra spaces or tabs were not being removed. This was fixed 28 Nov 2020, 008443d. The line now formats to
package Bob::Dog;For the parameter combination --indent-only and --closing-side-comments, old closing side comments were getting deleted but new closing side comments were not made. A fix was made to prevent this deletion. This fix was made 27 Nov 2020, 957e0ca.
Previously, for the combination --indent-only and -conv, two iterations would be done. Only one iteration is necessary in this case. Fix made 23 Nov 2020, ae493d8.
In developing an improved convergence test, an issue slowing convergence was found related to signed numbers as in the following line,
@london = (deg2rad(- 0.5), deg2rad(90 - 51.3));The leading '-' here is separated from the following number '0.5'. This is handled by tokenizing the minus as type 'm' and the number as type 'n'. The whitespace between them is removed in formatting, and so the space is gone in the output. But a little problem is that the default rule for placing spaces within the parens is based on the token count, after the first formatting the result is
@london = ( deg2rad( -0.5 ), deg2rad( 90 - 51.3 ) );The next time it is formatted, the '-0.5' counts as one token, resulting in
@london = ( deg2rad(-0.5), deg2rad( 90 - 51.3 ) );Notice that the space within the parens around the '-0.5' is gone. An update was made to fix this, so that the final state is reached in one step. This fix was made 23 Nov 2020, f477c8b.
A rare situation was identified during testing in which a block comment could be converted to be a hanging side comment. For example:
sub macro_get_names { #
#
# %name = macro_get_names(); (key=macrohandle, value=macroname)
#
local (%name) = ();
...
}For the following specific contitions the block comment in line 2 could be converted into a hanging side comment, which is undesirable:
1. The line contains nothing except for a '#' with no leading space
2. It follows a line with side comment
3. It has indentation level > 0An update was made to prevent this from happening. There are two cases, depending on the value of --maximum-consecutive-blank-lines, or -mbl. If this value is positive (the default) then a blank line is inserted above the block comment to prevent it from becoming a hanging side comment. If this -mbl is zero, then the comment is converted to be a static block comment which again prevents it from becoming a hanging side comment. This fix was made 23 Nov 2020, 2eb3de1.
A better test for convergence has been added. When iterations are requested, the new test will stop after the first pass if no changes in line break locations are made. Previously, at least two passes were required to verify convergnece unless the output stream had the same checksum as the input stream. Extensive testing has been made to verify the correctness of the new test. This update was made 23 Nov 2020, 29efb63.
An update was made to break vertical alignment when a new sequence of if-like statements or ternary statements is encountered. This situation was causing a loss of alignment in some cases. For example
OLD:
$m1 = 0;
if ( $value =~ /\bset\b/i ) { $m0 = 1; }
if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
if ( $m0 && !$m1 ) { $CONFIG[1] = 0; }
elsif ( !$m0 && $m1 ) { $CONFIG[1] = 1; }
else { $ok = 0; last; }
NEW:
$m1 = 0;
if ( $value =~ /\bset\b/i ) { $m0 = 1; }
if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
if ( $m0 && !$m1 ) { $CONFIG[1] = 0; }
elsif ( !$m0 && $m1 ) { $CONFIG[1] = 1; }
else { $ok = 0; last; }This update was made 15 Nov 2020, 2b7784d.
The parameter string can restrict the types of containers which are welded. This was added 11 Nov 2020 in 'added -wnxl=s for control of -wn', 2e642d2.
The man page gave the incorrect string for -fse. This was fixed 11 Nov 2020 in 1f9869e.
RPerl uses some bareword operators which caused error messages. An update was made to avoid this problem in files containing 'use RPerl'. This update was made 6 Nov 2020, f8bd088.
When -wn was set, the -vtc=n flag was being ignored. This was a simple fix made 5 Nov 2020 in 'fix issue git #45, -wn and -vtc=n now work together', 1fbc381.
These parameters request that old breakpoints be kept before or after selected token types. For example, -kbb='=>' means that newlines before fat commas should be kept. This was added 4 Nov 2020.
These parameters had tentatively been hardwired in the tokenizer. Now the user can control them or turn the checks off altogether.
In random testing, an error was encountered parsing the following line
$self->{"mod_id"}=($$*1001)%(10**(rand()*6));
---^
found Number where operator expected (previous token underlined)The line parsed correctly with a space between the '$$' and the '*'. The problem had to do with an error in some newer code for postfix dereferencing, and this was fixed on 2 Nov 2020, 'fix problem scanning '$$'; revise call to operator_expected', 49d993b.
The exit status was always 0 for --assert-tidy if the user had turned off error messages with -quiet. This was fixed by gluesys/master in 'fix exit status for assert-tidy/untidy options', 625d250.
A parsing error was encountered in a test parsing the following extruded signature:
sub foo2
(
$
first
,
$
,
$
third
)
{
return
"first=$first, third=$third"
;
}The second '$' combined with the ',' on the next line to form a punctuation variable. This was fixed 20 Oct 2020 in 'fixed problem parsing extruded signature', 9b454f6.
The file parses correctly now, with formatted output
sub foo2 ( $first, $, $third ) {
return "first=$first, third=$third";
}Several instances of incorrect array indexing were found in testing and fixed. These each involved incorrectly indexing with index -1. They were found by placing undefs at the end of arrays. None of these was causing incorrect formatting. They were fixed 26 Oct 2020 in 'fixed several instances of incorrect array indexing', c60f694.
In stress testing perltidy with the -extrude option, the following test snippet
use perl6-alpha;was broken into sepate lines
use
perl6
-
alpha
;A rule was added to prevent breaking around a dash separating two barewords. Rerunning gives
use
perl6-alpha
;This was fixed 26 Oct 2020 in 'prevent breaking package names with trailing dashes', 9234be4.
In stress testing perltidy with the -extrude option, using the following test snippet
my %var;
{
$var{-y} = 1;
$var{-q} = 1;
$var{-qq} = 1;
$var{-m} = 1;
$var{y} = 1;
$var{q} = 1;
$var{qq} = 1;
$var{m} = 1;
}a syntax error was created when newlines were placed before or after the dashes. It is necessary to always keep a dash on the same line with its surrounding tokens. A rule was added to do this. The new 'extruded' result for the above snippet is:
my%var
;
{
$var{-y}
=
1
;
$var{-q}
=
1
;
$var{-qq}
=
1
;
$var{-m}
=
1
;
$var{y}
=
1
;
$var{q}
=
1
;
$var{qq}
=
1
;
$var{m}
=
1
;
}This update was added 26 Oct 2020, 'prevent syntax error by breaking dashed barewords', e121cae.
Files for which 'severe errors' are found have always been output verbatim rather than being formatted. The definition of 'severe error' has been expanded to include a final indentation level error greater than 1, more than 2 brace errors, and more than 3 "unexpected token type" parsing errors. The goal is to avoid formatting a non-perl script or a perl script with severe errors. So for example the following snippet has a level error of 2
{{{{
}}was previously output with default parameters as
{
{
{
{}
}along with an error message. But now it is just output verbatim as
{{{{
}}along with an error message. This update was added 25 Oct 2020, 'avoid formatting files with more types of severe errors', 2a86f51.
A statement such as the following was generating an error message at the colon:
state $a : shared;The problem was that 'state' was not in the list of keywords. This has been fixed and the line now parses without error. The 'state.t' test file for perl 5.31 now formats without error. This was added 18 Oct 2020 in "add 'state' as keyword", d73e15f.
Simple signatures (those without commas) were being parsed with code originally written for prototypes. This prevented them from being formatted with the usual formatting rules. This was changed so that all signatures are now formatted with the normal formatting rules. For example:
# Old, input and after formatting:
sub t123 ($list=wantarray) { $list ? "list" : "scalar" }
# New, after formatting
sub t123 ( $list = wantarray ) { $list ? "list" : "scalar" }Notice that some spaces have been introduced within the signature. Previously the contents of the parens not changed unless the parens contained a list.
This change introduced a problem parsing extended syntax within signatures which has been fixed. In the following snippet, the ':' caused a parsing error which was fixed.
# perltidy -sal='method'
method foo4 ( $class : $bar, $bubba ) { $class->bar($bar) }The ':' here is given a type of 'A'. This may be used to change the spacing around it. For example:
# perltidy -sal='method' -nwls='A'
method foo4 ( $class: $bar, $bubba ) { $class->bar($bar) }This update was added 18 Oct 2020, in 'format all signatures separately from prototypes', e6a10f3. The test file 'signatures.t' distributed with perl5.31 formats without error now.
A problem with parsing variables of the form $# and $#array was found in testing and fixed. For most variables the leading sigil may be separated from the remaining part of the identifier by whitespace. An exception is for a variable beginning with '$#'. If there is any space between the '$' and '#' then the '#' starts a comment. So the following snippet is has valid syntax and is equivalent to $ans=40;
my $ #
#
ans = 40;This was being misparsed and was fixed 17 Oct 2020, in 'fixed parsing error with spaces in $#' a079cdb.
During testing the following error was found and fixed. Given the following input snippet:
get(
on_ready => sub ($worker) {
$on_ready->end;
return;
},
on_exit => sub ( $worker, $status ) { return; },
);The resulting formatting was
get(
on_ready => sub ($worker) {
$on_ready->end;
return;
}, on_exit => sub ( $worker, $status ) { return; },
);Notice that the break after the comma has been lost. The problem was traced to a short-cut taken by the code looking for one-line blocks. The unique circumstances in which this occured involved a hash of anonymous subs, one with a signature with multiple parameters and short enough to be a one-line block, as in the last sub definition line. This was fixed 17 Oct 2020 in 'fix missing line break for hash of subs with signatures', 51428db.
Problems with parsing prototypes and signatures were found during testing and fixed 17 Oct 2020 in 'fixed problem parsing multi-line signatures with comments', 017fd07. For example the following snippet was mis-parsed because of the hash mark.
sub test ( # comment )))
$x, $x) { $x+$y }Complex signature expressions such as the following are now parsed without error:
sub t086
( #foo)))
$ #foo)))
a #foo)))
) #foo)))
{ $a.$b }The following line caused a tokenization error in which the two slashes were parsed as a pattern.
my $masksize = ceil( Opcode::opcodes / 8 ); # /This problem was discovered in random testing. When a slash follows a bareword whose prototype is not known to perltidy, it has to guess whether the slash starts a pattern or is a division. The guessing logic was rewritten and improved 14 Oct 2020 in 'rewrote logic to guess if divide or pattern', afebe2f.
The flag -bos, or --break-at-old-semicolon-breakpoints, keeps breaks at old isolated semicolons. For example
$z = sqrt($x**2 + $y**2)
;In testing it was found not to be doing this after braces which require semicolons, such as 'do' and anonymous subs. This was fixed 12 Oct 2020 in 'fix -bos to work with semicolons after braces', 03ee7fc. For example
my $dist = sub {
$z = sqrt( $x**2 + $y**2 )
;
}
;If a line break occurs after use overload then it will now be kept. Previously it was dropped. For example, this would be kept intact:
use overload
'+' => sub {
print length $_[2], "\n";
my ( $x, $y ) = _order(@_);
Number::Roman->new( int $x + $y );
},
'-' => sub {
my ( $x, $y ) = _order(@_);
Number::Roman->new( int $x - $y );
},
...This keeps the list from shifting to the right and can avoid problems in formatting the list with certain styles, including with the -xci flag. Fixed 12 Oct 2020 in 'keep break after use overload statement', 8485afa.
This flag causes continuation indentation to "extend" deeper into structures. If you use -ci=n and -i=n with the same value of n you will probably want to set this flag. Since this is a fairly new flag, the default is -nxci to avoid disturbing existing formatting.
This problem is illustrated with the following snippet when run with -bli -blil='*'
#-bli -bli list='*'
try
{
die;
}
catch
{
die;
}; # <-- this was not indentingThis was due to conflicting rules and was fixed 1 Oct 2020 in commit 'fix issue git #40, incorrect closing brace indentation with -bli', a5aefe9.
At the same time, it was noted that block types sort/map/grep and eval were not following -bli formatting when -blil='*' and this was fixed. For example, with corrected formatting, we would have
# perltidy -bli -blil='*'
eval
{
my $app = App::perlbrew->new( "install-patchperl", "-q" );
$app->run();
}
or do
{
$error = $@;
$produced_error = 1;
};This is a detailed log of changes since the release 20200907. All bugs were found with the help of automated random testing.
In random testing, the -mangle option introduced a syntax error by deleting the space between barewords and quotes (test file 'MxScreen'), such as:
oops"Your login, $Bad_Login, is not valid";Sub 'is_essential_whitespace' was updated to prevent this on 27 Sep 2020, in 'keep any space between a bareword and quote', f32553c.
The .LOG file reports any disagreements between the indentation of the input and output files. This can help locate brace errors. These were incorrect when some of the options were used, including --whitespace-cycle, -bbhb, -nib. This was corrected 24 Sep 2020, 'fixed incorrect log entry for indentation disagreement', 3d40545. At the same time, locations of closing brace indentation disagreements are now tracked and reported in the .ERR file when there is a brace error. This can help localize the error if the file was previously formatted by perltidy.
Previously only a complaint was given, which went into the log file and was not normally seen. Perl silently accepts this but it can cause significant problems with pod utilities, so a clear warning is better. This situation arose in testing on random files in combination with a -dp flag and it took some time to understand the results because of the lack of a warning.
This is not a bug, but is cleaner coding and insures that error messages get reported. This change was made 20 Sep 2020, 'switch from eval { } to ->can('finish_formatting')', 28f2a4f.
The following message was generated during automated testing
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12079.
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12089.
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12097.The problem could be simplified to running perltidy -wn on this snippet:
__PACKAGE__->load_components( qw(
> Core
>
> ) );This was fixed 20 Sep 2020 in 'fixed_uninitialized_value', 8d6c4ed.
The following snippet was being incorrecly parsed:
print <<
# Hello World 13!
;
print "DONE\n";This is a deprecated here-doc without a specified target but currently still a valid program. It would have been correctly parsed if the semicolon followed the '<<' operator rather than the here-doc.
This was found in random testing and fixed 16 Sep 2020. A warning message about deprecated here-doc targets was added.
The -> can now be vertically aligned if a space is placed before it with -wls='->'. Added 15 Sep 2020 as part of previous item, 9ac6af6.
These flags give control over the opening token of a multiple-line list. They are described in the man pages, perltidy.html. Added 15 Sep 2020 in "added flags -bbhb=n, -bbsb=n, -bbq=n, suggestion git #38". 9ac6af6.
A change was made to allow a '=>' at the end of a line to align vertically, provided that it aligns with two or more other '=>' tokens. This update was 14 Sep 2020, 'Allow line-ending '=>' to align vertically', ea96739.
The following message was generated when running perltidy on random text:
Use of uninitialized value $K_semicolon in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.This was fixed 14 Sep 2020, included in 'Allow line-ending '=>' to align vertically', ea96739.
A rule was added to prevent a file consisting of a single semicolon
;from becoming a zero length file. This could cause problems with other software. Fixed 13 Sep 2020, 'do not create a zero length file by deleting semicolons', b39195e.
The following message was generated when running perltidy on random text:
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11926.
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11936.
Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11944.This was fixed 13 Sep 2020 in 'fixed unitialized variable problem ', adb2096.
The following message was generated when running perltidy on random text:
substr outside of string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.
Use of uninitialized value in concatenation (.) or string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.This was fixed 13 Sep 2020 in 'fixed unitialized variable problem', 5bf49a3.
The following message was generated when running perltidy on random text:
Use of uninitialized value $K_opening in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.This was fixed 13 Sep 2020 in 'fix undefined variable reference', 1919482.
The following snippet generated a warning that there might be a hash-bang after the start of the script.
$x = 2;
#! sunos does not yet provide a /usr/bin/perl
$script = "$^X $script";To prevent this annoyance, the warning is not given unless the first nonblank character after the '#!' is a '/'. Note that this change is just for the warning message. The actual hash bang check does not require the slash.
Fixed 13 Sep 2020, 'prevent unnecessary hash-bang warning message' 4f7733e and 'improved hash-bang warning filter', fa84904.
An unitialized index was referenced when running on a file of randomly generated text:
Use of uninitialized value $K_oo in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 7259.This was fixed 12 Sep 2020 in 'fixed undefined index', 616bb88.
The parameter combination -lp -wc triggered an internal bug message from perltidy:
398: Program bug with -lp. seqno=77 should be 254 and i=1 should be less than max=-1
713: The logfile perltidy.LOG may contain useful information
713:
713: Oops, you seem to have encountered a bug in perltidy. Please check the
713: BUGS file at http://perltidy.sourceforge.net. If the problem is not
713: listed there, please report it so that it can be corrected. Include the
...The problem is that the parameters --line-up-parentheses and --whitespace-cycle=n are not compatible. The fix is to write a message and turn off the -wc parameter when the both occur. This was fixed 8 Sep 2020 in "do not allow -wc and -lp together, can cause bugs", 7103781.
This snippet after processing with the indicated parameters triggered a Fault message in store-token-to-go due to discontinuous internal index values :
perltidy --noadd-newlines --space-terminal-semicolon
if ( $_ =~ /PENCIL/ ) { $pencil_flag= 1 } ; ;
$yy=1;This triggered the message:
==============================================================================
While operating on input stream with name: '<stdin>'
A fault was detected at line 7472 of sub 'Perl::Tidy::Formatter::store_token_to_go'
in file '/home/steve/bin/Perl/Tidy/Formatter.pm'
which was called from line 8298 of sub 'Perl::Tidy::Formatter::process_line_of_CODE'
Message: 'Unexpected break in K values: 591 != 589+1'
This is probably an error introduced by a recent programming change.
==============================================================================The deletion of the extra, spaced, comma had created an extra space in the token array which had not been forseen in the original programming. It was fixed 10 Sep 2020 in "fixed very rare fault found with automated testing", eb1b1d9.
This problem can be illustrated with this two-line snippet:
$#
eq$,?print"yes\n":print"no\n";Perltidy joined '$#' and 'eq' to get $#eq, but should have stopped at the line end to get $# followed by keyword 'eq'. (Note that $# is deprecated). This was fixed 11 Sep 2020 in "fixed several fringe parsing bugs found in testing", 85e01b7.
This problem can be illustrated with the following test snippet which was not correctly parsed.
print$$ <300?"$$<300\n":$$<700?"$$<700\n":$$<2_000?"$$<2,000\n":$$<10_000?"$$ <10,000\n":"$$>9,999\n";The problem is related to the '<' symbol following the '$$' variable, a possible filehandle, and is similar to a previous bug. The problem was corrected 11 Sep 2020 in "fixed several fringe parsing bugs found in testing", 85e01b7. The line now correctly formats to
print $$ < 300 ? "$$<300\n"
: $$ < 700 ? "$$<700\n"
: $$ < 2_000 ? "$$<2,000\n"
: $$ < 10_000 ? "$$ <10,000\n"
: "$$>9,999\n";A file with incorrect bracing which effectively gave negative indentation caused a crash when a stack was referenced with a negative index. The problem was fixed 8 Sept 2020 in "convert array to hash to avoid trouble with neg levels in bad files", a720e0d.
This error can be demonstrated with this line.
print $i <10 ? "yes" : "no";Perl has some strange parsing rules near a possible filehandle, and they change over time. The '<' here is a less than symbol, but perltidy expected that it might be the start of an angle operator, based on the old rules, and gave a warning. The formatting was still correct, but the warning was confusing. This has been fixed 8 Sep 2020 in 'remove confusing warning message', 0a4d725.
This problem is illustrated with the following snippet
$sth= $dbh->prepare (<<"END_OF_SELECT") or die "Couldn't prepare SQL" ;
SELECT COUNT(duration),SUM(duration)
FROM logins WHERE username='$user'
END_OF_SELECTWhen run with a short line length it got broken after the here target, causing an error. This was due to a recent program change and fixed 7 Sep 2020 in 'fixed bug where long line with here target got broken', 8f7e4cb.
An uninitialized value was being referenced and triggered this message:
undefined test2, i_opening=5, max=18, caller=Perl::Tidy::Formatter ./perltidy-20200907.pl 13465
Use of uninitialized value $test2 in numeric eq (==) at ./perltidy-20200907.pl line 19692.Fixed 8 Sep 2020 in 'fixed rare problem with stored index values for -lp option', 4147c8c.
This problem arose in several scripts involving the parameter --line-up-parentheses pluse one or more of the vertical tightness flags. It can be illustrated with the following snippet:
perltidy --line-up-parentheses --paren-vertical-tightness=1
if (
( $name, $chap ) =
$cur_fname =~ m!^Bible/
.*?/ # testament
.*?/ # range of books
(.*?)/ # book name
.*? # optional range of verses
(\d+)$!x
)
{
$cur_name = "$name $chap";
}This gave
if (( $name, $chap ) =
.*?/ # testament
$cur_fname =~ m!^Bible/
.*?/ # range of books
(.*?)/ # book name
.*? # optional range of verses
(\d+)$!x
)
{
$cur_name = "$name $chap";
}Notice the incorrect line order. The problem was an incorrect order of operations in the vertical aligner flush, leaving a line stranded and coming out in the wrong order. This was fixed 11 Sep 2020.
This crash was due to an index error which caused a non-existant object to be referenced. The problem is fixed 2020-09-07 in "fix problem of undefined values involving j_terminal_match", c5bfa77. The particular parameters which caused this were:
--noadd-newlines --nowant-left-space='=' This is not a bug but did take some time to resolve. The problem was reduced to the following script run with the -x flag (--look-for-hash-bang)
print(SCRIPT$headmaybe . <<EOB . <<'EOF' .$tailmaybe),$!;
#!$wd/perl
EOB
print "\$^X is $^X, \$0 is $0\n";
EOFThe resulting file had a syntax error (here-doc target EOB changed).
print(SCRIPT$headmaybe . <<EOB . <<'EOF' .$tailmaybe),$!;
#!$wd/perl
EOB print "\$^X is $^X, \$0 is $0\n";
EOFThe problem is that the -x flag tells perltidy not to start parsing until it sees a line starting with '#!', which happens to be in a here-doc in this case.
A warning was added to the manual 7 Sept 2020 in "add warning about inappropriate -x flag", fe66743.
This problem was reduced to the following snippet:
substr
(
$#
)The deprecated variable '$#' was being parsed incorrectly, and this was due to an error in which the word 'substr' followed by a paren was taken as the start of a sub signature. The problem was fixed 8 Sep 2020 in 'fix problem parsing sub prototypes' 569e05f. The code
$container_type =~ /^sub/;was corrected to be
$container_type =~ /^sub\b/;Unitialized values were referenced. An index was not being tested. Fixed 8 Sep 2020 in "fix undefined variable", 9729965.
Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4022.
Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.
Use of uninitialized value $Ko in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.These are known issues which have not been fixed.
Basic parsing of lexical subs works but some aspects of lexical subs are not yet functional. One of these is that unlike regular subs, lexical subs can override names of builtin functions.
First consider the following snippet
sub s {
my $arg=$_[0];
print "s called with arg $arg\n";
}
s(1);
s(2);The 's' in the two last lines is the builtin s function, not the sub. Both perltidy and perl make the same assumption here. This program happens to still run but prints nothing. It will not run if the last semicolon is removed.
Now consider the following snippet in which the sub has a preceding 'my'
use feature 'lexical_subs', 'signatures';
my sub s {
my $arg=$_[0];
print "s called with arg $arg\n";
}
s(1);
s(2);The builtin function 's' is replaced by the sub s here, and the program runs. Perltidy will format this but it is assuming that the s in the two last lines are the builtin s function. If the last semicolon is removed, there will be an formatting error. So perltidy and perl make different assumptions in this case.
Another issue is that perltidy does not yet remember the extent of the scope of a lexical sub.
Consider the following snippet:
use Test::More;
ok open($stdin, "<&", $1), 'open ... "<&", $magical_fileno', || _diag $!;Note the unusual situation of a comma followed by an '||'. Perltidy will format this satisfactorally but it will write an error message. The syntax is correct, however. Perl knows the prototype of the 'ok' function, which is called here without parens, so the last comma marks the last arg and is needed to keep the || from attaching to the last arg.
Full support of peren-less calls will probably never be implemented in perltidy because it would require that it parse all of the modules used to find the prototypes. This would make it impossible to run perltidy on small snippets of code from within an editor.
The problem can be avoid if parens are used:
ok ( open($stdin, "<&", $1), 'open ... "<&", $magical_fileno') || _diag $!;Perltidy currently flags as an error a closing paren followed by an opening paren, as in the following
$subsubs[0]()(0)This syntax is ok. The example is from test 'current_sub.t' in perl5.31.