Greg Korba

But Symfony 7.1 requires a higher PHP version and can have this in local config, while it can't be added as-is to the ruleset in this repository because it's tested...

Yes, exactly, it should be dynamic, based on PHP version. Thanks @nicolas-grekas for confirming 🙂. @seb-jean are you going to make CI green?

@seb-jean you should: - modify ruleset in a way where `trailing_comma_in_multiline.elements.parameters` is added dynamically, if runtime's version is 8.0+ (this will fix `"parameters" option can only be enabled with PHP...

Another option is to convert only `final` classes with all properties marked as `readonly`. For non-final classes we can break the code in inherited classes, so it's too risky IMHO.

FYI: Some ideas can be taken from #7089, also see #7171 (especially [this comment](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/issues/7171#issuecomment-1645441674) and [this conclusion](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/issues/7171#issuecomment-1645465439)).

@keradus if we have waited 10 days more with the release, this issue would have been solved exactly on its 7th birthday 😂.

@ruudk thanks for this feature request! I agree with it, but I've changed the title because: - it suggested resolution (technical detail), which should be chosen based on decision that...

I've prepared #7064 with rather safe change: - built-in fixers still has reserved "global namespace", e.g. `foo_bar` - custom fixers have to use either `foo/bar` convention or FQCN-like name with...

Is it still needed? There's PHPUnit 10 already 😉. I'm going to close this, but @keradus feel free to re-open it if you think we should provide such support.

I would rather add an configuration option to the fixer that would allow defining set of constants that should be considered as native. This way it would be flexible enough...