feat: require non-capturing catch#281
Conversation
Ocramius
left a comment
There was a problem hiding this comment.
LGTM, although very confusing inputs (don't see any diffs in the tests either 🤔 )
| <?php | ||
|
|
||
| declare(strict_types=1); | ||
|
|
||
| namespace Exceptions; |
There was a problem hiding this comment.
Are these files supposed to have no body? 🤔
There was a problem hiding this comment.
Yup, it's a base file and the body is added via 80 and 81 patches. No support in < 8
There was a problem hiding this comment.
Agree but not my call. Let's have @doctrine team do that.
There was a problem hiding this comment.
Honestly, why not? We run the cs jobs on PHP 8, and can use ^9.0 || ^10.0 as a version constraint on projects that need to support PHP 7.
There was a problem hiding this comment.
This repository does not contain any code, so I don't see a point in requiring a higher PHP version than the sum of our dependencies. @greg0ire is right that we don't run PHPCS itself on PHP 7 anymore, but we run it on code that needs to run on PHP 7.
What the test suite currently covers isn't running the ruleset on different PHP versions, but running it for different language levels. And we would still need that matrix, even if we bumped the min PHP version in composer.json to 8.2.
I understand that reviewing those patch files is cumbersome. Maybe it would be a little less painful if we created dedicated fixed folders per language level?
There was a problem hiding this comment.
Maybe it would be a little less painful if we created dedicated fixed folders per language level?
Inputs are also different for different PHP versions.
There was a problem hiding this comment.
I see. And do you think it would help to reverse the patching process? We'd keep all fixtures in the highest supported PHP language level (8.1 currently) and create patches for the lower levels? My expectation would be that PRs would become easier to review and it would be easier to drop old PHP versions eventually.
There was a problem hiding this comment.
Maintenance would still be PIA (since maintaining eoled phps sucks and there's too many versions already) but it may facilitate reviews, yes.
|
Thanks @simPod ! |
…ingCatch (#86) Introduced in doctrine/coding-standard#281
to avoid unused redundant variables in catch blocks