Generic/EmptyPHPStatement: inconsistent behavior when fixing superfluous semicolon

[rodrigoprimo]

Describe the bug

While working on #699, I noticed an inconsistency in how the Generic.CodeAnalysis.EmptyPHPStatement sniff fixes superfluous semicolons placed right after a PHP open tag when the PHP ini directive short_open_tag is enabled.

If a normal open tag is used, the superfluous semicolon is removed, and a space is left between the open tag and the rest of the code. If a shot open tag is used, no space is left between the open tag and the rest of the code. I'm inclined to think the sniff should behave the same for both types of open tags.

This is probably not a high-priority issue as the resulting code is not a parse error, and short open tags are not very popular.

Related to #593

Code sample

<?php ; my_function(); ?>

<? ; my_function(); ?>

To reproduce

Steps to reproduce the behavior:

1. Ensure that the short_open_tag ini directive is enabled.
2. Create a file called test.php with the code sample above.
3. Run phpcbf --standard=Generic --sniffs=Generic.CodeAnalysis.EmptyPHPStatement test.php
4. See that the resulting test.php file contains the following. Note there is no space between <? and my_function();.

<?php my_function(); ?>

<?my_function(); ?>

Expected behavior

I expect the sniff to preserve the space between <? and my_function();.

Versions (please complete the following information)

Operating System	Ubuntu 24.04
PHP version	8.3
PHP_CodeSniffer version	master
Standard	Generic
Install type	git clone

Please confirm

• I have searched the issue list and am not opening a duplicate issue.
• I have read the Contribution Guidelines and this is not a support question.
• I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards.
• I have verified the issue still exists in the master branch of PHP_CodeSniffer.

[jrfnl]

Leaving a single space after a short open tag makes sense to me and a PR to add special handling for short open tags would be welcome.
Though as you already said: low priority as it's not a parse error and AFAICS not a cause for fixer conflicts.