Incorrect rule count for set dropdown
https://getrector.com/find-rule?activeRectorSetGroup=php&rectorSet=php-php-85 looks like this:
Problem: The select dropdown mentions 7 rules, but the results only show 3 rules.
Expected result: Both numbers are consistent. (Alternatively: Remove the number from the set dropdown. There is also no number when only a group is selected, i.e. for "All sets".)
Probable cause: php85.php configures 7 rules, but only 3 of those are PHP 8.5 specific, the others are generic rules configured with configuration specific to PHP 8.5 changes.
Sounds valid. Could you send a PR with fix?
@TomasVotruba I can have a look to fix it. But would you like to remove the number in the dropdown or should it be corrected?
It would be better to correct it, whichever is wrong.
@TomasVotruba The fundamental issue, in my opinion, lies here:
https://github.com/rectorphp/getrector-com/blob/8175244e67329b0fe048dd945a197f10bf9311f4/src/Sets/RectorSetsTreeProvider.php#L103-L104
\Rector\Bridge\SetRectorsResolver::resolveFromFilePathIncludingConfiguration() returns an array of either rules class names if they are not configurable or nested array with configuration data resulting in the following rector set dump:
\App\RuleFilter\ValueObject\RectorSet::$rectorClasses however is only annotated to support an array of rule class names.
For the dropdown, the count considers all of these rules, thus the larger counter.
The filtered results view, however, uses
https://github.com/rectorphp/getrector-com/blob/8175244e67329b0fe048dd945a197f10bf9311f4/src/RuleFilter/RuleFilter.php#L115
to filter the rule set, which then calls
https://github.com/rectorphp/getrector-com/blob/8175244e67329b0fe048dd945a197f10bf9311f4/src/RuleFilter/ValueObject/RectorSet.php#L31
which relies on the annotated structure that the rector class names are just the class names, not the array with class name + configurations so that rector classes with indices 3-6 are filtered out from the screenshot above because they are never matched by in_array().
After having understood the reason for the issue, I am not sure what the desired result is: Is a rename rule specifically configured for a set meant to be shown here? Probably not because it would just show the generic rule without any set specific configuration?