Ensure PHPStan version stability

[teohhanhui]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	N/A
License	MIT
Doc PR	N/A

[soyuka]

Would be cleaner to merge this in 2.0, then merge 2.0 in master + only fix phpstan to avoid conflicts no?

WDYT?

[teohhanhui]

I don't think this would create conflicts, but I leave that up to whoever does the merge. 😛

[teohhanhui]

But sure, cleaner commit log lol...

[soyuka]

Hmm, the error is weird now :P.

[teohhanhui]

Yeah, it's weird. Could it have been caused by incorrect usage of PHPStan?

[teohhanhui]

Maybe @ondrejmirtes could help us figure this out. 😆

[meyerbaptiste]

The problem comes from this PR phpstan/phpstan#255 (comment) and the Symfony\Component\DependencyInjection\ExpressionLanguage class which extends a non-existent class.

But why does PHPStan analyze this class? We have no reference to this one in our codebase for this branch.

[ondrejmirtes]

I'll look into it, I'm sure there's some reason PHPStan tries to load this class.

[meyerbaptiste]

You're right @ondrejmirtes. PHPStan tries to load this class when it creates the type map of the Symfony\Component\DependencyInjection\ContainerBuilder class (we have many references to this one) which has an $expressionLanguage attribute (ExpressionLangage|null).

But errors at this level should not be displayed, right?

[ondrejmirtes]

Current behaviour is actually an improvement because in 0.7, the PHPStan process would crash on a fatal error. I'll evaluate this situation and get back to you.

[ondrejmirtes]

You can always put this in ignoreErrors :)

[mvrhov]

Do you need global require? PHPStan is now available as a phar.

[soyuka]

Thanks @teohhanhui