Reached maximum number of loops with 0 violations left unfixed .

[vol4onok]

Describe the bug

After upgrading to PHP_CodeSniffer 3.13.0, phpcbf fails to fix files containing a large number of fully qualified namespace violations. The command outputs "*** Reached maximum number of loops with 0 violations left unfixed ***" and reverts all fixes.

I have a PHP file with many fully qualified class names (e.g., \Full\Namespace\Class::class)
Run phpcbf on the file with rules that convert FQCN to short names with use statements
Observe the failure with PHPCS 3.13.0+
The same file fixes correctly with PHPCS 3.12.2
PHPCS 3.13.0+: Fails with loop limit error, no fixes applied
PHPCS 3.12.2: Works correctly, all fixes applied.

Code sample

# many cases when I use the full namespace to create the class, like
$one = new \One\Class();
$two = new \Two\Class();
....
$array = [new \Array\Class(), [new \Array1\Class(), new \Array1\Class()]]
# class has ~100 issues like this, might be some cs issues like withspace, missed docblock, etc.

Custom ruleset

I have a lot of rules.

To reproduce

Steps to reproduce the behavior:

1. Create a file called test.php with the code sample above...
2. Run phpcs test.php ...
3. See the error message displayed

PHPCS output here

Expected behavior

A clear and concise description of what you expected to happen.

Versions (please complete the following information)

Operating System	(e.g., [Ubuntu 22.04.5 LTS)
PHP version	(e.g., 7.2, 8.1)
PHP_CodeSniffer version	(e.g., 3.13.0)
Standard	(dfferent)
Install type	(e.g. Composer local

Additional context

Add any other context about the problem here.

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 4.x branch of PHP_CodeSniffer.

[jrfnl]

@vol4onok Thanks for opening this issue. Unfortunately, there is nothing actionable in it. Not even a way to reproduce the issue to allow for debugging.

I suggest you create a minimal reproduction sample - as in: small code sample with the ruleset downsized to the problem rule(s).

The command outputs "*** Reached maximum number of loops with 0 violations left unfixed ***" and reverts all fixes.

PHPCBF doesn't work that way. Only the last failed fixes would be reverted. So all fixes being reverted indicates that there is a fixer conflict starting from the first loop. (scratch that, it does revert and does so more consistently since 3.13.0 / PR #1048)

If you use the -vv flag when running against one (1) file only, you get an awful lot of output, but at the bottom you should see the fixer transscript which will tell you which sniff(s) are causing the conflict (if there is a conflict).