v2.x PHPStan extension is incompatible with PHPStan 2

[mortenscheel]

Hello,

Carbon v2.x is incompatible with PHPStan v2 when using macros.
When encountering a Carbon macro, PHPStan crashes with

Internal error: Class "PHPStan\Reflection\Php\BuiltinMethodReflection" does not exist while analysing file /path/to/file.php

Specifically it's crashing on this line:

Carbon/src/Carbon/PHPStan/Macro.php

Line 20 in 4df0fdd

$method = new ReflectionMethod(BuiltinMethodReflection::class, 'getReflection');

Is it possible to backport the updated extension from v3.x?

Carbon version: 2.72.5

PHP version: 8.3.14

Thanks!

[adnweedon]

This would be really helpful for us as well - I did have a look at whether I could raise a PR but can't make head nor tail of what it's trying to do!

[kylekatarnls]

Hello, Carbon 2.x is no longer supported. With a very limited work force, I'm focusing on 3.x version (released for ~1 year) and shaping what 4.x would be. I cannot afford to support (review, test, maintain) new features/versions supports added in 2.x branch.

However if you cannot upgrade to Carbon 3 and need it, you can still try to add vendor/nesbot/carbon/lazy/Carbon/PHPStan/AbstractMacroBuiltin.php (or the AbstractMacroStatic one, I didn't test what's needed for PHPStan 2) and vendor/nesbot/carbon/lazy/Carbon/PHPStan/MacroStrongType.php in the PHPStan bootstrapFiles, then yet another custom file that just does:

<?php
namespace Carbon\PHPStan;
final class Macro extends LazyMacro
{
}

[mortenscheel]

Thanks @kylekatarnls I'll give it a try when I have time.

If anyone else gets it to work before, it would be nice if you could share a fork (assuming it won't be merged here).

[kylekatarnls]

I would still discourage forking, you wouldn't then benefit from security updates that can still happen on 2.x branch. Instead it could be achieved with just some extra bootstrap files to load a custom Carbon\PHPStan\Macro class (so to override only this class and not the whole package), it might just fit in a single file, but if it takes more, then it could go in a bridge package; that would be way safest than a fork, mainly knowing that it's actually needed only for static analysis (should be require-dev only, not in the require entry of the composer.json).