<ul id="index">
+ <li><a href="#Issues-fixed-after-release-20211029">Issues fixed after release 20211029</a></li>
<li><a href="#Issues-fixed-after-release-20210625">Issues fixed after release 20210625</a></li>
<li><a href="#Issues-fixed-after-release-20210402">Issues fixed after release 20210402</a></li>
<li><a href="#Issues-fixed-after-release-20210111">Issues fixed after release 20210111</a></li>
<li><a href="#Open-Issues">Open Issues</a></li>
</ul>
+<h1 id="Issues-fixed-after-release-20211029">Issues fixed after release 20211029</h1>
+
+<dl>
+
+<dt id="Fix-tokenization-issue-c109"><b>Fix tokenization issue c109</b></dt>
+<dd>
+
+<p>Automated random testing produced an error tokenizing the following code fragment:</p>
+
+<pre><code> s s(..)(.)sss
+ ;</code></pre>
+
+<p>This is equivalent to 's/(..)(.)//s' with 's' as the delimiter instead of '/'. It was tokenized correctly except when the final 's' was followed by a newline, as in the example. When the delimiter is a letter rather than a punctuation character, perltidy exercises some seldom-used code which had an off-by-one loop limit. This has been fixed.</p>
+
+<p>12 Nov 2021.</p>
+
+</dd>
+<dt id="Fix-tokenization-of-issue-c106"><b>Fix tokenization of $$^, issue c106</b></dt>
+<dd>
+
+<p>Automated random testing produced an error tokenizing the following fragment:</p>
+
+<pre><code> my$seed=$$^$^T;</code></pre>
+
+<p>The first ^ should have been tokenized as the bitwise xor operator but was not. This is fixed with this update.</p>
+
+<p>8 Nov 2021</p>
+
+</dd>
+<dt id="Fix-coding-error-issue-c104"><b>Fix coding error, issue c104</b></dt>
+<dd>
+
+<p>Automated random testing produced an error with something like the following input line taken from an obfuscated perl script:</p>
+
+<pre><code> open(IN, $ 0);</code></pre>
+
+<p>The '0' was missing in the output:</p>
+
+<pre><code> open( IN, $ );</code></pre>
+
+<p>The tokenization was correct, but a line of code in the formatter which removes the space between the '$' and the '0' should have used a 'defined' when doing a check:</p>
+
+<pre><code> $token .= $word if ($word); # OLD: error</code></pre>
+
+<p>This if test fails on '0'. The corrected line is</p>
+
+<pre><code> $token .= $word if ( defined($word) ); # NEW: fixes c104</code></pre>
+
+<p>This fixes the problem and gives the correct formatted result</p>
+
+<pre><code> open( IN, $0 );</code></pre>
+
+<p>8 Nov 2021.</p>
+
+</dd>
+<dt id="Fix-undefined-variable-reference-c102"><b>Fix undefined variable reference, c102</b></dt>
+<dd>
+
+<p>Random testing produced an undefined variable reference for the following input</p>
+
+<pre><code> make_sorter ( sort_sha => sub {sha512 ( $_} );
+ make_sorter ( sort_ids => sub {/^ID:(\d+)/} );</code></pre>
+
+<p>when formatted with the following input parameters:</p>
+
+<pre><code> --space-function-paren
+ --maximum-line-length=26
+ --noadd-newlines</code></pre>
+
+<p>Notice that the input script has a peculiar syntax error - the last two closing tokens of the first line are transposed. (Ironically, this snippet is taken from code which accompanied the book Perl Best Practices). The perltidy tokenizer caught the syntax error, but the formatter touched an undefined variable while attempting to do the formatting. It would be possible to just skip formatting for errors like this, but it can sometimes help finding bugs to see an attempted formatting. So the formatter coding has been corrected to avoid the undefined variable reference.</p>
+
+<p>This fixes issue c102.</p>
+
+<p>5 Nov 2021.</p>
+
+</dd>
+<dt id="Some-blocks-with-side-comments-exceed-line-length"><b>Some blocks with side comments exceed line length</b></dt>
+<dd>
+
+<p>In some rare cases, one-line blocks with side comments were exceeding the line length limit. These usually had a semicolon between the closing block brace and the side comment. For example:</p>
+
+<pre><code> my $size
+ = do { local $^W; -f $local && -s _ }; # no ALLO if sending data from a pipe</code></pre>
+
+<p>This update breaks the one-line block in an attempt to keep the total length below the line length limit. The result on the above is:</p>
+
+<pre><code> my $size = do {
+ local $^W;
+ -f $local && -s _;
+ }; # no ALLO if sending data from a pipe</code></pre>
+
+<p>Note that this break can be prevented by including the flag --ignore-side-comment-lengths or -iscl.</p>
+
+<p>3 Nov 2021.</p>
+
+</dd>
+</dl>
+
<h1 id="Issues-fixed-after-release-20210625">Issues fixed after release 20210625</h1>
<dl>
+<dt id="Fix-c090-inconsistent-warning-messages-for-deprecated-syntax"><b>Fix c090, inconsistent warning messages for deprecated syntax</b></dt>
+<dd>
+
+<p>For something like the following snippet, a warning about deprecated syntax was either going into the error file or the log file, depending on formatting. This has been fixed.</p>
+
+<pre><code> do $roff ( &verify($tpage) );</code></pre>
+
+<p>20 Oct 2021, 72e4bb1.</p>
+
+</dd>
+<dt id="Fix-c091-incorrect-closing-side-comment"><b>Fix c091, incorrect closing side comment</b></dt>
+<dd>
+
+<p>An error was discovered and corrected in the behavior of the --closing-side-comment (-csc) flag when only subs were being marked with the setting -cscl='sub'. The problem was that in rare cases a closing paren could be marked with '## end'. The cause of the problem is that the pattern matching regex which was generated for this case happens to match an empty string, and it could happen that certain parens had empty strings as block names. This was fixed in two ways. First, the regex was fixed so that it cannot match an empty string. Second, a test for an empty string was added.</p>
+
+<p>20 Oct 2021, aa1a019.</p>
+
+</dd>
+<dt id="Issue-c089-improve-vertical-alignment-for-lists-without-parens"><b>Issue c089, improve vertical alignment for lists without parens</b></dt>
+<dd>
+
+<p>An update was made to improve vertical alignment in situations where parens are omitted around lists. The goal is to make lists without parens align as they would if they were contained in parens. Some examples:</p>
+
+<pre><code> # OLD, no parens, no alignment:
+ glVertex3d $cx + $s * $xs, $cy, $z;
+ glVertex3d $cx, $cy + $s * $ys, $z;
+ glVertex3d $cx - $s * $xs, $cy, $z;
+ glVertex3d $cx, $cy - $s * $ys, $z;
+
+ # OLD, with parens and aligned:
+ glVertex3d( $cx + $s * $xs, $cy, $z );
+ glVertex3d( $cx, $cy + $s * $ys, $z );
+ glVertex3d( $cx - $s * $xs, $cy, $z );
+ glVertex3d( $cx, $cy - $s * $ys, $z );
+
+ # NEW, no parens but aligned
+ glVertex3d $cx + $s * $xs, $cy, $z;
+ glVertex3d $cx, $cy + $s * $ys, $z;
+ glVertex3d $cx - $s * $xs, $cy, $z;
+ glVertex3d $cx, $cy - $s * $ys, $z;
+
+ # OLD
+ mkTextConfig $c, $x, $y, -anchor => 'se', $color;
+ mkTextConfig $c, $x + 30, $y, -anchor => 's', $color;
+ mkTextConfig $c, $x + 60, $y, -anchor => 'sw', $color;
+ mkTextConfig $c, $x, $y + 30, -anchor => 'e', $color;
+
+ # NEW
+ mkTextConfig $c, $x, $y, -anchor => 'se', $color;
+ mkTextConfig $c, $x + 30, $y, -anchor => 's', $color;
+ mkTextConfig $c, $x + 60, $y, -anchor => 'sw', $color;
+ mkTextConfig $c, $x, $y + 30, -anchor => 'e', $color;
+
+ # OLD
+ permute_test [ 'a', 'b', 'c' ], '/', '/', [ 'a', 'b', 'c' ];
+ permute_test [ 'a,', 'b', 'c,' ], '/', '/', [ 'a,', 'b', 'c,' ];
+ permute_test [ 'a', ',', '#', 'c' ], '/', '/', [ 'a', ',', '#', 'c' ];
+ permute_test [ 'f_oo', 'b_ar' ], '/', '/', [ 'f_oo', 'b_ar' ];
+
+ # NEW
+ permute_test [ 'a', 'b', 'c' ], '/', '/', [ 'a', 'b', 'c' ];
+ permute_test [ 'a,', 'b', 'c,' ], '/', '/', [ 'a,', 'b', 'c,' ];
+ permute_test [ 'a', ',', '#', 'c' ], '/', '/', [ 'a', ',', '#', 'c' ];
+ permute_test [ 'f_oo', 'b_ar' ], '/', '/', [ 'f_oo', 'b_ar' ];
+
+ # OLD:
+ is $thingy, "fee", "source filters apply to evalbytten strings";
+ is "foo", $unfiltered_foo, 'filters leak not out of byte evals';
+ is $av->[2], "NAME:my_xop", "OP_NAME returns registered name";
+ is $av->[3], "DESC:XOP for testing", "OP_DESC returns registered desc";
+ is $av->[4], "CLASS:$OA_UNOP", "OP_CLASS returns registered class";
+ is scalar @$av, 7, "registered peep called";
+ is $av->[5], "peep:$unop", "...with correct 'o' param";
+ is $av->[6], "oldop:$kid", "...and correct 'oldop' param";
+
+ # NEW
+ is $av->[2], "NAME:my_xop", "OP_NAME returns registered name";
+ is $av->[3], "DESC:XOP for testing", "OP_DESC returns registered desc";
+ is $av->[4], "CLASS:$OA_UNOP", "OP_CLASS returns registered class";
+ is scalar @$av, 7, "registered peep called";
+ is $av->[5], "peep:$unop", "...with correct 'o' param";
+ is $av->[6], "oldop:$kid", "...and correct 'oldop' param";</code></pre>
+
+<p>20 Oct 2021, 1dffec5.</p>
+
+</dd>
+<dt id="Issue-c087-breaking-after-anonymous-sub"><b>Issue c087, breaking after anonymous sub</b></dt>
+<dd>
+
+<p>This update keeps both of these configurations stable for all cases except when the -lp option is used. For the -lp option, both become one-line blocks (the second case) to prevents the -lp indentation style from being lost. This update was made to minimize changes to existing formatting.</p>
+
+<pre><code> $obj = {
+ foo => sub { "bar" }
+ };
+
+ $obj = { foo => sub { "bar" } };</code></pre>
+
+<p>17 Oct 2021, f05e6b5.</p>
+
+</dd>
+<dt id="Improve-formatting-of-some-Moose-structures"><b>Improve formatting of some Moose structures</b></dt>
+<dd>
+
+<p>In some structures used in Moose coding, some asymmetrical container breaks were being caused by the braces being tokenized as hash braces rather than block braces. This was also causing some unwanted warning messages.</p>
+
+<pre><code> # OLD
+ ::is(
+ ::exception { has '+bar' => ( default => sub { 100 } );
+ },
+ undef,
+ '... extended the attribute successfully'
+ );
+
+ # NEW
+ ::is(
+ ::exception {
+ has '+bar' => ( default => sub { 100 } );
+ },
+ undef,
+ '... extended the attribute successfully'
+ );</code></pre>
+
+<p>This fixes issue c074.</p>
+
+<p>12 Oct 2021, 7e873fa.</p>
+
+</dd>
+<dt id="Fix-issue-c081--cscw-preventing-deletion-of-closing-side-comments"><b>Fix issue c081, -cscw preventing deletion of closing side comments</b></dt>
+<dd>
+
+<p>Random testing revealed a problem in which an old closing side comment was not being deleted when it fell below the interval specified on -csci=n and the -cscw flag was also set.</p>
+
+<p>For example, the following snippet has been formatted with -csc -csci=1. The interval -csci=1 insures that all blocks get side comments:</p>
+
+<pre><code> if ($x3) {
+ $zz;
+ if ($x2) {
+ if ($x1) {
+ ..;
+ } ## end if ($x1)
+ $a;
+ $b;
+ $c;
+ } ## end if ($x2)
+ } ## end if ($x3)</code></pre>
+
+<p>If we then run with -csc -csci=6, the comment ## end if ($x1) will fall below the threshold and be removed (correctly):</p>
+
+<pre><code> if ($x3) {
+ $zz;
+ if ($x2) {
+ if ($x1) {
+ ..;
+ }
+ $a;
+ $b;
+ $c;
+ } ## end if ($x2)
+ } ## end if ($x3)</code></pre>
+
+<p>But if we also add the -cscw flag (warnings) then it was not being removed. This update fixes this problem (issue c081).</p>
+
+<p>2 Oct 2021, 25ef8e8</p>
+
+</dd>
+<dt id="Partial-fix-for-issue-git-74-on--lp-at-anonymous-subs"><b>Partial fix for issue git #74 on -lp at anonymous subs</b></dt>
+<dd>
+
+<p>In the following snippet, the final one-line anonymous sub is not followed by a comma. This caused the -lp mode to revert to standard indentation mode because a forced line break was being made after the closing sub brace:</p>
+
+<pre><code> # OLD, perltidy -lp
+ $got = timethese(
+ $iterations,
+ {
+ Foo => sub { ++$foo },
+ Bar => '++$bar',
+ Baz => sub { ++$baz }
+ }
+ );</code></pre>
+
+<p>An update was made to check for and fix this.</p>
+
+<pre><code> # NEW, perltidy -lp
+ $got = timethese(
+ $iterations,
+ {
+ Foo => sub { ++$foo },
+ Bar => '++$bar',
+ Baz => sub { ++$baz }
+ }
+ );</code></pre>
+
+<p>But note that this only applies to one-line anonymous subs. If an anonymous sub is broken into several lines due to its length or complexity, then these forced line breaks cause indentation to revert to the standard indentation scheme.</p>
+
+<p>22 Sep 2021, 4fd58f7.</p>
+
+</dd>
+<dt id="Fix-issues-b1209-related-to--vmll"><b>Fix issues b1209 related to -vmll</b></dt>
+<dd>
+
+<p>Testing with random parameters produced a formatting instability related to the -vmll flag. The problem was due to a subtle difference in the definition of nesting depth and indentation level. The vertical aligner was using nesting depth instead of indentation level to compute the maximum line length when -vmll is set. In some rare cases there is a difference. The problem was fixed by passing the maximum line length to the vertical aligner so that the calculation is only done in the formatter. This fixes b1209.</p>
+
+<p>20 Sep 2021, acf1d2d.</p>
+
+</dd>
+<dt id="Fix-issue-b1208"><b>Fix issue b1208</b></dt>
+<dd>
+
+<p>Testing with random parameters produced a formatting instability which could be triggered when there is a short line length limit and there is a long side comment on the closing brace of a sort/map/grep/eval block. The problem was due to not correctly including the length of the side comment when testing to see if the block could fit on one line. This update fixes issue b1208.</p>
+
+<p>18 Sep 2021, 0af1321.</p>
+
+</dd>
+<dt id="Fix-issue-git-73"><b>Fix issue git #73</b></dt>
+<dd>
+
+<p>The -nfpva parameter was not working correctly for functions called with pointers. For example</p>
+
+<pre><code> # OLD: perltidy -sfp -nfpva
+ $self->method ( 'parameter_0', 'parameter_1' );
+ $self->method_with_long_name ( 'parameter_0', 'parameter_1' );
+
+ # FIXED: perltidy -sfp -nfpva
+ $self->method ( 'parameter_0', 'parameter_1' );
+ $self->method_with_long_name ( 'parameter_0', 'parameter_1' );</code></pre>
+
+<p>The problem had to do with how the pointer tokens '->' are represented internally and has been fixed.</p>
+
+<p>17 Sep 2021,e3b4a6f.</p>
+
+</dd>
+<dt id="Fix-unusual-parsing-error-b1207"><b>Fix unusual parsing error b1207</b></dt>
+<dd>
+
+<p>Testing with random parameters produced another instability caused by misparsing an 'x' operator after a possible file handle. This is very similar to b1205, but involves a sigil immediately following a times operator.</p>
+
+<p>To illustrate some cases, consider:</p>
+
+<pre><code> sub x {print "arg is $_[0]\n"}
+ my $num = 3;
+ my @list=(1,2,3);
+ my %hash=(1,2,3,4);
+ open (my $fh, ">", "junk.txt");
+ print $fh x$num; # prints a GLOB $num times to STDOUT
+ print $fh x9; # prints 'x9' to file 'junk.txt'
+ print $fh x@list; # prints a GLOB 3 times to STDOUT
+ print $fh x%hash; # prints a GLOB 2 times to STDOUT</code></pre>
+
+<p>Note in particular the different treatment of the first two print statements.</p>
+
+<p>This update fixes case b1207.</p>
+
+<p>15 Sep 2021, 107586f.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-b1206"><b>Fix formatting instability b1206</b></dt>
+<dd>
+
+<p>Testing with random parameters produced an instability due welding with a very short line length and large value of -ci. This is similar to issues b1197-b1204 and fixed with a similar method.</p>
+
+<p>14 Sep 2021, 9704cd7.</p>
+
+</dd>
+<dt id="Fix-unusual-parsing-error-b1205"><b>Fix unusual parsing error b1205</b></dt>
+<dd>
+
+<p>Testing with random parameters produced an instability caused by misparsing an 'x' operator after a possible file handle. Testing with Perl showed that an 'x' followed by a '(' in this location is always the 'times' operator and never a call to a function 'x'. If x is immediately followed by a number it is subject to the usual weird parsing rules at such a location.</p>
+
+<p>To illustrate, consider what these statements do:</p>
+
+<pre><code> open( my $zz, ">", "junk.txt" );
+ sub x { return $_[0] } # never called
+ print $zz x(2); # prints a glob 2 times; not a function call
+ print $zz x 2; # prints a glob 2 times
+ print $zz x2; # syntax error
+ print $zz x; # syntax error
+ print $zz z; # prints 'z' in file 'junk.txt'</code></pre>
+
+<p>This update fixes case b1205.</p>
+
+<p>13 Sep 2021, cfa2515.</p>
+
+</dd>
+<dt id="Use-stress_level-to-fix-cases-b1197-b1204"><b>Use stress_level to fix cases b1197-b1204</b></dt>
+<dd>
+
+<p>Testing with random input parameters produced a number of cases of unstable formatting. All of these involved some combination of a short maximum line length, a large -ci and -i, and often one or more of -xci -lp and -wn. These parameters can force lines to break at poor locations. All of these cases were fixed by introducing a quantity called the 'stress_level', which is the approximate indentation level at which the line break logic comes under high stress and become unstable. For default parameters the stress level is about 12, but unusual parameter combinations can make it much less, even as low as zero. For code which is at an indentation level greater than this depth, some defensive actions are taken to avoid instability, such as temporarily turning off the -xci flag when the indentation depth exceeds the stress level. Most actual working code will not be influenced by this logic. Actual code which has a very deep indentation level can avoid problems by using a long line length, a short number of indentation spaces, or even the whitespace-cycle parameter.</p>
+
+<p>This update fixes issues b1197 b1198 b1199 b1200 b1201 b1202 b1203 b1204</p>
+
+<p>12 Sep 2021, 0ac771e.</p>
+
+</dd>
+<dt id="Fix-unusual-hanging-side-comment-issue-c070"><b>Fix unusual hanging side comment issue, c070</b></dt>
+<dd>
+
+<p>This issues can be illustrated with the following input script:</p>
+
+<pre><code> {
+ if ($xxx) {
+ ...
+ } ## end if ($xxx ...
+ # b <filename>:<line> [<condition>]
+ }
+
+
+ # OLD: perltidy -fpsc=21
+ {
+ if ($xxx) {
+ ...;
+ } ## end if ($xxx ...
+ # b <filename>:<line> [<condition>]
+ }</code></pre>
+
+<p>The comment '# b ..' moved over to the column 21 to the right as if it were a side comment. The reason is that it accidentally got marked as a hanging side comment. It should not have been because the previous side comment was a closing side comment. This update fixes this:</p>
+
+<pre><code> # NEW: perltidy -fpsc=21
+ {
+ if ($xxx) {
+ ...;
+ } ## end if ($xxx ...
+
+ # b <filename>:<line> [<condition>]
+ }</code></pre>
+
+<p>This fixes issue c070.</p>
+
+<p>10 Sep 2021, ec6ccf9.</p>
+
+</dd>
+<dt id="Fix-parsing-issue-c068"><b>Fix parsing issue c068</b></dt>
+<dd>
+
+<p>This issue is illustrated with the following line:</p>
+
+<pre><code> my $aa = $^ ? "defined" : "not defined";</code></pre>
+
+<p>If we tell perltidy to remove the space before the '?', then the output will no longer be a valid script:</p>
+
+<pre><code> # perltidy -nwls='?':
+ my $aa = $^? "defined" : "not defined";</code></pre>
+
+<p>The problem is that Perl considers '$^?' to be a special variable. So Rerunning perltidy on this gives an error, and perl also gives an error. This update fixes the problem by preventing a space after anything like '$^' from being removed a new special variable would be created.</p>
+
+<p>This fixes issue c068.</p>
+
+<p>7 Sep 2021, 9bc23d1.</p>
+
+</dd>
+<dt id="Fix-parsing-problem-issue-c066"><b>Fix parsing problem issue c066</b></dt>
+<dd>
+
+<p>This issue is illustrated with the following line (rt80058):</p>
+
+<pre><code> my $ok=$^Oeq"linux";</code></pre>
+
+<p>Running perltidy generated a warning message which is caused by the lack of space before the 'eq'. This update fixes the problem.</p>
+
+<p>4 Sep 2021, df79a20.</p>
+
+</dd>
+<dt id="Fix-unusual-parsing-problem-issue-c065"><b>Fix unusual parsing problem issue c065</b></dt>
+<dd>
+
+<p>Testing produced an unusual parsing problem in perltidy which can be illustrated with the following simple script:</p>
+
+<pre><code> my $str = 'a'x2.2;
+ print $str,"\n";</code></pre>
+
+<p>Normally an integer would follow the 'x' operator, but Perl seems to accept any valid number and truncates it to an integer. So in this case the number 2.2 is truncated to 2 and the output is 'aa'.</p>
+
+<p>But perltidy, with default parameters, formats this as</p>
+
+<pre><code> my $str = 'a' x 2 . 2;
+ print $str,"\n";</code></pre>
+
+<p>which prints the result "aa2". The problem is fixed with this update. With the update, the result is</p>
+
+<pre><code> my $str = 'a' x 2.2;
+ print $str, "\n";</code></pre>
+
+<p>which is equivalent to the original script.</p>
+
+<p>This fixes issue c065.</p>
+
+<p>4 Sep 2021, f242f78.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-issues-b1195-b1196"><b>Fix formatting instability issues b1195, b1196</b></dt>
+<dd>
+
+<p>Testing with random parameters produced two similar cases of unstable formatting which are fixed with this update.</p>
+
+<p>28 Aug 2021, ab9ad39.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-issue-b1194"><b>Fix formatting instability issue b1194</b></dt>
+<dd>
+
+<p>Testing with random parameters produced a case of unstable formatting which is fixed with this update.</p>
+
+<p>This fixes case b1194, and at the same time it simplifies the logic which handles issues b1183 and b1191.</p>
+
+<p>21 Aug 2021, 62e5b01.</p>
+
+</dd>
+<dt id="Fix-some-problems-involving-tabs-characters-case-c062"><b>Fix some problems involving tabs characters, case c062</b></dt>
+<dd>
+
+<p>This update fixes some problems found in random testing with tab characters. For example, in the following snippet there is a tab character after 'sub'</p>
+
+<pre><code> do sub : lvalue {
+ return;
+ }</code></pre>
+
+<p>Running perltidy on this repeatedly keep increasing the space between 'sub' and ':'</p>
+
+<pre><code> # OLD: perltidy
+ do sub : lvalue {
+ return;
+ }
+
+ # OLD: perltidy
+ do sub : lvalue {
+ return;
+ }</code></pre>
+
+<p>etc.</p>
+
+<pre><code> # NEW: perltidy
+ do sub : lvalue {
+ return;
+ }</code></pre>
+
+<p>Problems like this can occur if string comparisons use ' ' instead of the regex \s when working on spaces. Several instances of this were located and corrected.</p>
+
+<p>This fixes issue c062.</p>
+
+<p>18 Aug 2021, d86787f.</p>
+
+</dd>
+<dt id="Correct-parsing-error-case-c061"><b>Correct parsing error, case c061</b></dt>
+<dd>
+
+<p>Testing with random input produced an error condition involving a side comment placed between a sub name and prototype, as in the following snippet:</p>
+
+<pre><code> sub
+ witch # sc
+ () # prototype may be on new line ...
+ { print "which?\n" }
+ witch();</code></pre>
+
+<p>The current version of perltidy makes an error:</p>
+
+<pre><code> # OLD: perltidy
+ sub witch # sc () # prototype may be on new line ...
+ { print "which?\n" }
+ witch();</code></pre>
+
+<p>This update corrects the problem:</p>
+
+<pre><code> # NEW: perltidy
+ sub witch # sc
+ () # prototype may be on new line ...
+ { print "which?\n" }
+ witch();</code></pre>
+
+<p>This fixes case c061;</p>
+
+<p>18 Aug 2021, 3bb2b2c.</p>
+
+</dd>
+<dt id="Improved-line-break-case-c060"><b>Improved line break, case c060</b></dt>
+<dd>
+
+<p>The default formatting produced an undesirable line break at the last '&&' term in the following:</p>
+
+<pre><code> my $static = grep {
+ $class =~ /^$_$/
+ || $fullname =~ /^$_$/
+ || $method_name =~ /^$_$/
+ && ( $class eq 'main' )
+ } grep { !m![/\\.]! } $self->dispatch_to; # filter PATH</code></pre>
+
+<p>This update corrects this to give</p>
+
+<pre><code> my $static = grep {
+ $class =~ /^$_$/
+ || $fullname =~ /^$_$/
+ || $method_name =~ /^$_$/ && ( $class eq 'main' )
+ } grep { !m![/\\.]! } $self->dispatch_to; # filter PATH</code></pre>
+
+<p>15 Aug 2021, 9d1c8a9.</p>
+
+</dd>
+<dt id="Fix-error-check-caused-by--wn--iscl-case-c058"><b>Fix error check caused by -wn -iscl, case c058</b></dt>
+<dd>
+
+<p>Testing with random parameters triggered an an internal error check. This was caused by a recent coding change which allowed a weld across a side comment. The problem was in the development version, not in the latest released version, and is fixed with this update. This closes issue c058.</p>
+
+<p>14 Aug 2021, 5a13886.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-b1193"><b>Fix formatting instability, b1193</b></dt>
+<dd>
+
+<p>Testing with random parameters produced unstable formatting involving parameters which included -lp -sbvtc=1. This update fixes this problem, case b1193.</p>
+
+<p>13 Aug 2021, d4c3425.</p>
+
+</dd>
+<dt id="Fix-error-in-tokenizer-issue-c055"><b>Fix error in tokenizer, issue c055</b></dt>
+<dd>
+
+<p>The ultimate cause of the undefined variable reference in the previous issue was found to be a typo in the tokenizer. This update finishes fixing issue c055.</p>
+
+<p>10 Aug 2021, 2963db3</p>
+
+</dd>
+<dt id="Fix-undefined-variable-reference-in-development-version"><b>Fix undefined variable reference in development version</b></dt>
+<dd>
+
+<p>In testing, the following unbalanced snippet caused a reference to an undefined value in the current development version (but not in the current released version).</p>
+
+<pre><code> if($CPAN::Config->{term_is_latin}){
+ $swhat=~s{([\xC0-\xDF])([\x80-\xBF])}{chr(ord($1)<<6&0xC0|ord($2)&0x3F)}eg;}if($self->colorize_output){if($CPAN::DEBUG&&$swhat=~/^Debug\(/){
+ $ornament=$CPAN::Config->{colorize_debug}||"black on_cyan";}</code></pre>
+
+<p>A check has been added to fix this.</p>
+
+<p>10 Aug 2021, a3f9774.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-b1192"><b>Fix formatting instability, b1192</b></dt>
+<dd>
+
+<p>Testing with random parameters produced unstable formatting with the following snippet when run with some unusual parameters:</p>
+
+<pre><code> @EXPORT =
+ ( @{$EXPORT_TAGS{standard}}, );</code></pre>
+
+<p>It was also be formatted as</p>
+
+<pre><code> @EXPORT = (
+ @{$EXPORT_TAGS{standard}},
+ );</code></pre>
+
+<p>The problem was that a list formatting style was turning on and off due to the the needless terminal comma within the parens. A patch was made to ignore commas like this when deciding if list formatting should be used.</p>
+
+<p>This fixes case b1192.</p>
+
+<p>10 Aug 2021, b949215.</p>
+
+</dd>
+<dt id="Fix-formatting-instability-b1191"><b>Fix formatting instability, b1191</b></dt>
+<dd>
+
+<p>Random testing produced an instability involving an unusual parameter combination and the following input code:</p>
+
+<pre><code> $_[0]eq$_[1]
+ or($_[1]=~/^([!~])(.)([\x00-\xff]*)/)
+ and($1 eq '!')
+ ^(eval{($_[2]."::".$_[0])=~/$2$3/;});</code></pre>
+
+<p>This update fixes case b1191.</p>
+
+<p>9 Aug 2021, 16b4575.</p>
+
+</dd>
+<dt id="Fix-error-parsing-sub-attributes-without-spaces-b1190"><b>Fix error parsing sub attributes without spaces, b1190</b></dt>
+<dd>
+
+<p>Testing with random parameters produced an instability which was caused by incorrect parsing of a sub attribute list without spaces, as in</p>
+
+<pre><code> sub:lvalue{"a"}</code></pre>
+
+<p>This update fixes case b1190.</p>
+
+<p>9 Aug 2021, 7008bcc.</p>
+
+</dd>
+<dt id="Fix-rare-loss-of-vertical-alignment-in-welded-containers-c053"><b>Fix rare loss of vertical alignment in welded containers, c053</b></dt>
+<dd>
+
+<p>This update corrects a rare loss of vertical alignment in welded containers.</p>
+
+<p>To illustrate the issue, the normal formatting of the following snippet is</p>
+
+<pre><code> # perltidy -sil=1
+ ( $msg, $defstyle ) = do {
+ $i == 1 ? ( "First", "Color" )
+ : $i == 2 ? ( "Then", "Rarity" )
+ : ( "Then", "Name" );
+ };</code></pre>
+
+<p>If it appears within a welded container, the alignment of the last line was being lost:</p>
+
+<pre><code> # OLD: perltidy -wn -sil=1
+ { {
+
+ ( $msg, $defstyle ) = do {
+ $i == 1 ? ( "First", "Color" )
+ : $i == 2 ? ( "Then", "Rarity" )
+ : ( "Then", "Name" );
+ };
+ } }</code></pre>
+
+<p>The corrected result is</p>
+
+<pre><code> # NEW: perltidy -wn -sil=1
+ { {
+
+ ( $msg, $defstyle ) = do {
+ $i == 1 ? ( "First", "Color" )
+ : $i == 2 ? ( "Then", "Rarity" )
+ : ( "Then", "Name" );
+ };
+ } }</code></pre>
+
+<p>Several other minor vertical alignment issues are fixed with this updated. The problem was that two slightly different measures of the depth of indentation were being compared in the vertical aligner.</p>
+
+<p>This fixes case c053.</p>
+
+<p>8 Aug 2021, 97f02ee.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1189"><b>Fix edge case of formatting instability, b1189</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of unstable formatting involving welding with parameter -notrim-qw. The problem was that the -notrim-qw flag converts a qw quote into a quote with fixed leading whitespace. The lines of these types of quotes which have no other code are are output early in the formatting process, since they have a fixed format, so welding does not work. In particular, the closing tokens cannot be welded if they are on a separate line. This also holds for all types of non-qw quotes. So welding can only be done if the first and last lines of a non-qw quote contain other code. A check for this was added.</p>
+
+<p>For example, in the following snippet the terminal '}' is alone on a line:</p>
+
+<pre><code> is eval(q{
+ $[ = 3;
+ BEGIN { my $x = "foo\x{666}"; $x =~ /foo\p{Alnum}/; }
+ $t[3];
+ }
+ ), "a";</code></pre>
+
+<p># In the previous version this was half-welded: # OLD: perltidy -wn -sil=0</p>
+
+<pre><code> is eval( q{
+ $[ = 3;
+ BEGIN { my $x = "foo\x{666}"; $x =~ /foo\p{Alnum}/; }
+ $t[3];
+ }
+ ),
+ "a";</code></pre>
+
+<p>The new check avoids welding in this case, giving</p>
+
+<pre><code> # NEW: perltidy -wn -sil=0
+ is eval(
+ q{
+ $[ = 3;
+ BEGIN { my $x = "foo\x{666}"; $x =~ /foo\p{Alnum}/; }
+ $t[3];
+ }
+ ),
+ "a";</code></pre>
+
+<p>Welding can still be done if the opening and closing container tokens have other code. For example, welding can be done for the following snippet:</p>
+
+<pre><code> is eval(q{
+ $[ = 3;
+ BEGIN { my $x = "foo\x{666}"; $x =~ /foo\p{Alnum}/; }
+ $t[3];
+ }), "a";</code></pre>
+
+<p>And welding can still be done on all qw quotes unless the -notrim-qw flag is set.</p>
+
+<p>This fixes case b1189.</p>
+
+<p>7 Aug 2021, e9c25f2.</p>
+
+</dd>
+<dt id="Fix-edge-cases-of-formatting-instability-b1187-b1188"><b>Fix edge cases of formatting instability, b1187 b1188</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced some cases of instability involving -wn -lp and several other parameters. The mechanism involved an interaction between the formatter and vertical aligner.</p>
+
+<p>This fixes cases b1187 and b1188.</p>
+
+<p>3 Aug 2021, 5be949b.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1186"><b>Fix edge case of formatting instability, b1186</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of instability involving parameter -lp -pvt=n and a short maximum line length.</p>
+
+<p>This fixes case b1186.</p>
+
+<p>2 Aug 2021, f3dbee1.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1185"><b>Fix edge case of formatting instability, b1185</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of welding instability involving parameters -wn, -vt=2, -lp and a short maximum line length.</p>
+
+<p>This fixes case b1185.</p>
+
+<p>1 Aug 2021, d2ab2b7.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1183"><b>Fix edge case of formatting instability, b1183</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of welding instability involving parameters -wn, -vt=n, -lp. This update fixes the problem.</p>
+
+<p>This fixes case b1183.</p>
+
+<p>30 Jul 2021, 055650b.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1184"><b>Fix edge case of formatting instability, b1184</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of welding instability involving a tripple weld with parameters -wn, -vt=n, -lp. This update fixes the problem.</p>
+
+<p>This fixes case b1184.</p>
+
+<p>29 Jul 2021, 6dd53fb.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability-b1182"><b>Fix edge case of formatting instability, b1182</b>.</dt>
+<dd>
+
+<p>Testing with random parameters produced a case of welding instability involving unusual parameters and welding long ternary expressions. This update fixes the problem.</p>
+
+<p>This fixes case b1182.</p>
+
+<p>28 Jul 2021, 01d6c40.</p>
+
+</dd>
+<dt id="Fix-edge-case-of-formatting-instability"><b>Fix edge case of formatting instability</b>.</dt>
+<dd>
+
+<p>Random testing with random input parameters produced cases of formatting instability involving welding with unusual parameter settings. This update makes a small tolarance adjustment to fix it.</p>
+
+<p>This fixes cases b1180 b1181.</p>
+
+<p>28 Jul 2021, b38ccfc.</p>
+
+</dd>
+<dt id="Fix-rare-problem-with-formatting-nested-ternary-statements"><b>Fix rare problem with formatting nested ternary statements</b></dt>
+<dd>
+
+<p>This update fixes an extremely rare problem in formatting nested ternary statements, illustrated in the following snippet:</p>
+
+<pre><code> # OLD: There should be a break before the '?' in line 11 here:
+ WriteMakefile(
+ (
+ $PERL_CORE ? ()
+ : (
+ (
+ eval { ExtUtils::MakeMaker->VERSION(6.48) }
+ ? ( MIN_PERL_VERSION => '5.006' )
+ : ()
+ ),
+ (
+ eval { ExtUtils::MakeMaker->VERSION(6.46) } ? (
+ META_MERGE => {
+ #
+ }
+ )
+ : ()
+ ),
+ )
+ ),
+ );
+
+ # NEW: Line 12 correctly begins with a '?'
+ WriteMakefile(
+ (
+ $PERL_CORE ? ()
+ : (
+ (
+ eval { ExtUtils::MakeMaker->VERSION(6.48) }
+ ? ( MIN_PERL_VERSION => '5.006' )
+ : ()
+ ),
+ (
+ eval { ExtUtils::MakeMaker->VERSION(6.46) }
+ ? (
+ META_MERGE => {
+ #
+ }
+ )
+ : ()
+ ),
+ )
+ ),
+ );</code></pre>
+
+<p>This fixes issue c050, 63784d8.</p>
+
+<p>22 Jul 2021.</p>
+
+</dd>
+<dt id="Fix-conflict-of--bom-and--scp-parameters"><b>Fix conflict of -bom and -scp parameters</b></dt>
+<dd>
+
+<p>Automated testing with random parameters produced a case of instability caused by a conflict of parameters -bom and -scp. In the following script the -bom command says to keep the tokens ')->' on a new line, whereas the -scp command says to stack the closing paren on the previous line.</p>
+
+<pre><code> $resource = {
+ id => $package->new_from_mana(
+ $result->{data}
+ )->id
+ };</code></pre>
+
+<p>The parameters are:</p>
+
+<pre><code> --break-at-old-method-breakpoints
+ --indent-columns=8
+ --maximum-line-length=60
+ --stack-closing-paren</code></pre>
+
+<p>This caused an instability which was fixed by giving priority to the -bom flag. The stable state is then</p>
+
+<pre><code> $resource = { id => $package->new_from_mana(
+ $result->{data}
+ )->id };</code></pre>
+
+<p>This fixes case b1179.</p>
+
+<p>21 Jul 2021, 4ecc078.</p>
+
+</dd>
+<dt id="Fix-problems-with--kgb-in-complex-structures"><b>Fix problems with -kgb in complex structures</b></dt>
+<dd>
+
+<p>This update fixes two problems involving the -kgb option.</p>
+
+<p>The first problem is that testing with random parameters produced some examples of formatting instabilities involving applying --keyword-group-blanks to complex structures, particularly welded structures. The -kgb parameters work well on simple statements or simple lists, so a check was added to prevent them from working on lists which are more than one level deep. This fixes issues b1177 and b1178 without significantly changing the -kgb functionality.</p>
+
+<p>The second problem is that a terminal blank line could be misplaced if the last statement was a structure. This is illustrated with the following snippet:</p>
+
+<pre><code> sub new {
+ my $class = shift;
+ my $number = shift || croak "What?? No number??\n";
+ my $classToGenerate = shift || croak "Need a class to generate, man!\n";
+ my $hash = shift; #No carp here, some operators do not need specific stuff
+ my $self = { _number => $number,
+ _class => $classToGenerate,
+ _hash => $hash };
+ bless $self, $class; # And bless it
+ return $self;
+ }
+
+ # OLD: perltidy -kgb -sil=0 gave
+ sub new {
+
+ my $class = shift;
+ my $number = shift || croak "What?? No number??\n";
+ my $classToGenerate = shift || croak "Need a class to generate, man!\n";
+ my $hash = shift; #No carp here, some operators do not need specific stuff
+ my $self = {
+ _number => $number,
+
+ _class => $classToGenerate,
+ _hash => $hash
+ };
+ bless $self, $class; # And bless it
+ return $self;
+ }</code></pre>
+
+<p>The blank line which has appeared after the line '_number =>' was intended to go after the closing brace but a line count was off. This has been fixed:</p>
+
+<pre><code> # NEW: perltidy -kgb -sil=0 gives
+ sub new {
+
+ my $class = shift;
+ my $number = shift || croak "What?? No number??\n";
+ my $classToGenerate = shift || croak "Need a class to generate, man!\n";
+ my $hash = shift; #No carp here, some operators do not need specific stuff
+ my $self = {
+ _number => $number,
+ _class => $classToGenerate,
+ _hash => $hash
+ };
+
+ bless $self, $class; # And bless it
+ return $self;
+ }</code></pre>
+
+<p>This fixes issue c048.</p>
+
+<p>19 Jul 2021, 071a3f6.</p>
+
+</dd>
+<dt id="Fix-to-keep-from-losing-blank-lines-after-a-code-skipping-section"><b>Fix to keep from losing blank lines after a code-skipping section</b></dt>
+<dd>
+
+<p>A problem in the current version of perltidy is that a blank line after the closing code-skipping comment can be lost if there was a blank line before the start of the code skipping section. For example, given the following code:</p>
+
+<pre><code> $x = 1;
+
+ #<<V
+ % # = ( foo => 'bar', baz => 'buz' );
+ print keys(%#), "\n";
+ #>>V
+
+ @# = ( foo, 'bar', baz, 'buz' );
+ print @#, "\n";</code></pre>
+
+<p>running perltidy gives:</p>
+
+<pre><code> $x = 1;
+
+ #<<V
+ % # = ( foo => 'bar', baz => 'buz' );
+ print keys(%#), "\n";
+ #>>V
+ @# = ( foo, 'bar', baz, 'buz' );
+ print @#, "\n";</code></pre>
+
+<p>Notice that the blank line after the closing comment #>>V is missing. What happened is that the formatter is counting blank lines and did not 'see' the code skipping section. So the blank after the closing comment looked like the second blank in a row, so it got removed since the default is --maximum-consecutive-blank-lines=1.</p>
+
+<p>This update fixes this by resetting the counter. This fixes case c047. A simple workaround until the next release is to include the parameter</p>
+
+<p>--maximum-consecutive-blank-lines=2, or -mbl=2.</p>
+
+<p>It can be removed after the next release.</p>
+
+<p>18 Jul 2021, 9648e16.</p>
+
+</dd>
+<dt id="Fix-possible-welding-instability-in-ternary-after-fat-comma"><b>Fix possible welding instability in ternary after fat comma</b></dt>
+<dd>
+
+<p>Random testing produced a case of formatting instability involving welding within a ternary expression following a fat comma:</p>
+
+<pre><code> if ( $op and $op eq 'do_search' ) {
+ @{$invoices} =
+ GetInvoices(
+ shipmentdatefrom =>
+ $shipmentdatefrom ? output_pref( {
+ str => $shipmentdatefrom,
+ dateformat => 'iso'
+ } )
+ : undef,
+ publicationyear => $publicationyear,
+ );
+ }</code></pre>
+
+<p>when the following specific parameters were used</p>
+
+<pre><code> --extended-continuation-indentation
+ --line-up-parentheses
+ --maximum-line-length=38
+ --variable-maximum-line-length
+ --weld-nested-containers</code></pre>
+
+<p>This update fixes this issue, case b1174.</p>
+
+<p>18 Jul 2021, 12ae46b.</p>
+
+</dd>
+<dt id="Fix-mis-tokenization-before-pointer"><b>Fix mis-tokenization before pointer</b></dt>
+<dd>
+
+<p>Random testing produced the following case in which formatting was unstable because the variable '$t' was being mis-tokenized as a possible indirect object.</p>
+
+<pre><code> --break-before-all-operators
+ --ignore-old-breakpoints
+ --maximum-line-length=22
+ -sil=0
+
+ my $json_response
+ = decode_json $t
+ ->tx->res->content
+ ->get_body_chunk;</code></pre>
+
+<p>This update fixes cases b1175, b1176.</p>
+
+<p>17 Jul 2021, 4aa1318.</p>
+
+</dd>
<dt id="Fix-to-make--wn-and--bbxx-n-flags-work-together"><b>Fix to make -wn and -bbxx=n flags work together</b></dt>
<dd>
<p>This update fixes case b1173. It works for any number of welded containers, and the -bbxxi=n flags also work correctly.</p>
-<p>16 Jul 2021.</p>
+<p>16 Jul 2021, c71f882.</p>
</dd>
<dt id="Fix-problem-with-side-comment-after-pattern"><b>Fix problem with side comment after pattern</b></dt>
projects / perltidy.git / blobdiff