Allow Eagerly Resolving Deprecations #7898
Closed
Kenneth-Sills wants to merge 5 commits intorectorphp:mainfrom
Closed
Allow Eagerly Resolving Deprecations #7898Kenneth-Sills wants to merge 5 commits intorectorphp:mainfrom
Kenneth-Sills wants to merge 5 commits intorectorphp:mainfrom
Conversation
Required, as test success is currently order-dependent and may prevent running specific subgroups of tests. The reason being that the PHP version is set via simple parameters, which are global and previously unable to be unset. Some tests required setting the specific version of PHP, which would end up pinning that version until the next test that required a specific version. If the prior version was too low, it could cause later tests not to execute at all, breaking things. You could not set the version parameter to `null` because it's always accessed via `provideIntParameter(...)`, which does type-checking.
This will allow us to implement eager deprecation resolution for PHP version ranges. Test cases have been added to make sure the feature works correctly, but also that no rules in the PHP upgrade pipeline are misconfigured in an obvious way.
…rsioning Since all PHP migration rules required a minimum version (per custom linting rule), and I wanted to make sure we were being clear _why_, I've introduced a new baseline constant in the PHP version features dictionary; this indicates that whatever rule can ALWAYS be run. I *believe* this covers everything, but it's hard to audit the whole ruleset.
This allows this rule to be applied one minor version earlier in "eager" mode, since DNF type specifications came one step after intersection types themselves. I was originally just going to bump the required PHP version up to 8.2, but I saw precedence for adding version guards in other rules: - ReturnTypeFromStrictTypedCallRector - AddParamTypeDeclarationRector - IsIterableRector So when PHP 8.1 is a possibility, we can still *reduce* the number of deprecations without fully committing to them all.
Member
|
This would introduce extreme complexity and make upgrade path much ambiguous. |
Contributor
Author
|
Unless I'm misunderstanding, every PHP migration rule must already specify the minimum required PHP version for that rule to be applied, right? Deprecation rules just "cheat" by using a much higher version than actually required and over-filtering themselves. The only change here is allowing a rule to specify both and remove the difference between deprecation and non-deprecation rules. EDIT: Though, I suppose most other rules add a specific feature whose fix is easier to define the minimum version of... Unless you mean to say that Rector does not natively support applications, tooling, or libraries that must support PHP version ranges? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Parent Ticket: rectorphp/rector#9646
This introduces three primary changes:
ExplicitNullableParamTypeRector, allowing it to run for PHP 8.1 without using not-yet-existing syntax (intersection types added in 8.1, but DNF types added in 8.2).Since the changeset is rather large, I've made sure the changes are broken up step-by-step in the commit history. Each message should provide more specific details on what was changed / why.
All checks and tests have been run locally and passed.
A follow-up ticket for documentation changes in "PHP Version Features" (site, repo) can be expected.