-
Notifications
You must be signed in to change notification settings - Fork 51
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
feat: require non-capturing catch #281
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these files supposed to have no body? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's just drop php 7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree but not my call. Let's have @doctrine team do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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