Php-cs-fixer: Braces - PHP closing tag moved to previous closing brace

[C-Duv]

The _braces_ rules is moving PHP closing tag next to previous closing brace and I don't see why (which fixer says so) nor how to prevent it from doing it.

The PHP version:

=> 7.3.17-1+ubuntu18.04.1+deb.sury.org+1

PHP CS Fixer version:

=> PHP CS Fixer 2.16.3 Yellow Bird

PHP CS Fixer command ran:

=> ./vendor/bin/php-cs-fixer fix --diff -v --using-cache=no

Configuration file (.php_cs.dist file):

<?php
$finder = PhpCsFixer\Finder::create()
    ->in('samples')
;
return PhpCsFixer\Config::create()
    ->setFinder($finder)
;

Minimum samples of PHP code:

• Before running PHP CS Fixer (no changes):

<?php

if (true) {
    ?>
<hr />
    <?php
    if (true) {
        echo 'x';
    }
    ?>
<hr />
    <?php
}

• Unexpected changes applied when running PHP CS Fixer:

The _braces_ rule is triggered and the second PHP closing tag ?> (from line 10) moves next to the previous closing brace } (to line 9).

--- Original
+++ New
@@ @@
         echo 'x';
-    }
-    ?>
+    } ?>
 <hr />
     <?php
 }

Here is sample "fixed" by PHP CS Fixer:

<?php

if (true) {
    ?>
<hr />
    <?php
    if (true) {
        echo 'x';
    } ?>
<hr />
    <?php
}

• Changes I expected instead:

I expected no changes, at least not for the PHP closing tag ?>.

<?php

if (true) {
    ?>
<hr />
    <?php
    if (true) {
        echo 'x';
    }
    ?>
<hr />
    <?php
}

[SpacePossum]

Hi and thanks for reporting,

Wondering if can fix this in https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/4884 or if its worth fixing in the current fixer, WDYT @julienfalque ?

[julienfalque]

I'd vote for fixing the bug in #4884 to avoid fixing it twice, but that means it will not be released until the PR is merged, which might be in a while.

[C-Duv]

Waiting for #4884 is fine for me: as long as you got the info :)

[julienfalque]

Actually this is already fixed by #4884: I added a test case and it passes without extra changes.

[C-Duv]

Thanks for checking this :+1:
I guess I can close this issue andl watch #4884.