This should be checked by version in Rector. If on PHP 8.0+, this should be skipped.
And new downgrade rule added to make it safe

The downgrade rule need to exists first then, as without this, the cast string will be removed at

• Add note for substr() can return false on php 7.x on ClassLikeNameClassNameImportSkipVoter #7438

and add back the regression bug.

After downgrade rule created, then we can safely remove this check.

Please revert this first and add PHP version check, so we don't create regressions in existing rule.
Then make a downgrade rule 🙏

There is no need php version check, as phpstan already check it when run on php 7.x, just need add skip config in rector.php for now:

        // on php 7.x, substr() result can return false, so force (string) is needed
        RecastingRemovalRector::class => [
            __DIR__ . '/rules/CodingStyle/ClassNameImport/ClassNameImportSkipVoter/ClassLikeNameClassNameImportSkipVoter.php',
        ],

see

• [DeadCode] Skip ClassLikeNameClassNameImportSkipVoter for RecastingRemovalRector #7448

Instead of changing existing fixture, always make a new one. To make clear former one works.

it is the old fixture behaviour, see previous PR revert:

• https://github.com/rectorphp/rector-src/pull/7442/files#diff-eed5e1102c1bf8506422cf19f0639eaf581346432ded2b7a2bdb8f4f638048ce

This is original fixture before the changes train, see PR order changes:

• [DeadCode] Skip remove cast (string) on substr as may return false on php 7.x on RecastingRemovalRector #7442 (change to strtoupper due to cause issue on type declaration set)
• Directly check type of substr() on RecastingRemovalRector #7446 (This PR back to original, only change the RecastingRemovalRector only)
• [DeadCode] Skip ClassLikeNameClassNameImportSkipVoter for RecastingRemovalRector #7448 (Next, I only back to skip via rector.php, and add test for cast removal for (string) substr() for RecastingRemovalRector)

Same as before, do not change fixture, but rather add new one. Renaming a fuction that we talk about is confusing to read.

@samsonasik Exactly my point. Instead of renaming fixture content back and forth and having to read 3 PRs to understand, they should be always related only to current PR. These PRs should be independent on each other, standalone units.