-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[3.2.3 BC break] New error reporting added in MultipleStatementAlignment #1911
Comments
The fact that it previously wasn't being reported was a bug - see #1870, so why shouldn't it have been in a bugfix release ? |
Because new errors being reported are BC breaks and i.e. break CI builds. |
That's not how PHPCS works. The main job of PHPCS is to detect and report coding standard violations in your code. So when something needs to be fixed, the reason is because PHPCS is either:
There are cases where internal code changes are made to solve issues that are not outwardly visible, but most bug fixes solve one of the two points above. That means that almost every bug fix either:
Bug fix #1870 falls into category 2, where the sniff was incorrectly seeing your example code as two different code blocks due to the semi-colon in your closure. It was a pretty clear bug in the end, so it's been fixed in a bug fix release. Does that explain this issue a bit better? |
@gsherwood this makes a lot of sense, so I think we'll just have to deal with this minor instability. |
@gsherwood Thanks for your reply. Although I still think #1870 could've been fixed without introducing new error reporting in bugfix release and leaving it at least to next minor (i.e. remove incorrect reporting, leave out the fixed behavior for next minor). Tracking breaking changes in bugfix releases is nightmare for consumers. |
That's exactly what I'm going for. I see this as a pretty clear bug fix. The sniff was written before closures and anon classes existed and it just never got support for them. If I didn't fix bugs, PHPCS would obviously report the exact same errors for the exact same code forever, but then it would never improve its error detection or future PHP version support.
In this particular case, it looks to me like the originally reported code is basically the same structure as the code you've posted here, so I don't know how I can report an error for one and not the other. I think the only thing I could have done is add a config option to allow people to tell PHPCS to ignore closures and anon classes, but you still would have had to change your ruleset to enable this option if you wanted that code to remain valid. |
This code worked fine in 3.2.2:
Now reports an error in 3.2.3:
As much as I understand that it could be considered as a one assignment group, introducing new error for this in a bugfix release is a BC break.
The text was updated successfully, but these errors were encountered: