- Notifications
You must be signed in to change notification settings - Fork 1.5k
Closed
Description
Describe the bug
phpcs:enable
can sometimes wind up overriding a later phpcs:ignore
for the rule. This can particularly happen when multiple phpcs:enable
comments are present in the file.
Code sample
<?php // phpcs:disable PSR12.Operators.OperatorSpacing.NoSpaceBefore // phpcs:disable PSR12.Operators.OperatorSpacing.NoSpaceAfter $x=1; // phpcs:enable PSR12.Operators.OperatorSpacing.NoSpaceAfter // phpcs:enable PSR12.Operators.OperatorSpacing.NoSpaceBefore $x= 2; // phpcs:ignore PSR12.Operators.OperatorSpacing.NoSpaceBefore
Custom ruleset
N/A
To reproduce
Steps to reproduce the behavior:
- Create a file called
test.php
with the code sample above. - Run
phpcs -s --standard=PSR12 test.php
- See error message displayed
FILE: /tmp/test/test.php --------------------------------------------------------------------------------------------------------------- FOUND 1 ERROR AFFECTING 1 LINE --------------------------------------------------------------------------------------------------------------- 9 | ERROR | [x] Expected at least 1 space before "="; 0 found | | (PSR12.Operators.OperatorSpacing.NoSpaceBefore) --------------------------------------------------------------------------------------------------------------- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY ---------------------------------------------------------------------------------------------------------------
Expected behavior
The error on line 9 should have been ignored due to the phpcs:ignore
comment on that line.
Versions (please complete the following information)
Operating System | Debian sid |
PHP version | 8.2.10 |
PHP_CodeSniffer version | 3.7.2, master |
Standard | PSR12 |
Install type | Composer local |
Additional context
It seems that in this situation it's setting $ignoring['.except'][...]
, which overrides phpcs:ignore
.
Please confirm:
- I have searched the issue list and am not opening a duplicate issue.
- 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.