The reason this sniff doesn't auto-fix itself is because the code produced by the fix is not equivalent to the original in all cases. In this sniff, that's due to operator precedence.

For this reason, fixing is mostly confined to just formatting changes.

A fix for this code would need to ensure that there are no other operators in use that would cause precedence issues. Then the sniff could replace the token, knowing that the statement would be evaluated in exactly the same way.

If you'd like to have a go at that, I'd be happy to review a PR. But I can't merge this one in due to the above reason.

I gave it a try. How bad is it? ;)

I've had a quick look, but I think I'd need to see a lot of test cases before I could commit a change like this. I can add unit tests myself, but it would be good to see the test code and edge cases you worked with because I don't have a heap of time to do it right now, and it would be good to know how you came up with that blacklist.

There also doesn't seem to be any checking of grouped statements, so I wonder if this sniff might be tricked into not fixing something because it is looking at the whole statement and not just a bracketed part of a condition.

The blacklist is based on PHP's manual.
While working on the PR i started to wonder if this might be the first Sniff that isn't able to fix ALL errors it finds. That would at least explain why the Abstract Test doesn't differentiate between fixable and not fixable errors. I'm not used to writing test cases for static code analysis so i might've missed something.

Edit: I just added the T_LOGICAL_XOR and T_BOOLEAN_OR depending on which operator we're facing.

I'm currently finalising the changes for the 3.0 release and trying to stabilise the 2.x branch. That means that I will not be adding any features that I think change the behaviour of 2.x too much, or cause it to potentially become unstable.

This changes has the potential to cause instability due to auto-fixing changes, so I would prefer it to go into the 3.x branch only so the 2.x behaviour is not affected.

it's a very worthwhile change that I would like to see in PHPCS, and you've taken the time to produce a lot of tests cases, so I hope you're able to re-target it for 3.x. If not, please let me know and I'll make the changes myself.

See PHPCSStandards/PHP_CodeSniffer#613