The webmozart assert extension failures are interesting. Did you decipher those already? Maybe I added invalid closure phpdoc somewhere or so?

The type of self::$resolvers inside the closure is now the assigned value from the outer scope, which is generalized because of the foreach. If you rewrite the closure to an arrow function you'd get the same error because arrow functions already inherit all expression types from the outer scope.

There's 2 obvious solutions (if this PR was to go through): unroll the foreach into 3 separate resolvers, or extract the string resolver into a variable and use that instead.

$this->foo is skipped because $this is a variable. Arrow functions behave the same way, which is why I took this approach.

If this isn't desirable, I'd like your opinion on the discrepancy between closures and arrow functions: https://phpstan.org/r/4241be28-13e8-49d0-bc6e-298a99f88df9

Please see: #1934 (comment)

I think to solve the bug report, we need to opt-in just a few specific expressions to retain their type when entering an anonymous function:

• function_exists
• class_exists
• defined (so ConstFetch)

If this isn't desirable, I'd like your opinion on the discrepancy between closures and arrow functions:

Looking at ondrrej's example in #1934 (comment) same thing can be said for arrow functions (like https://3v4l.org/bp59b)
I'm now thinking that the current behavior for the arrow function should be fixed instead, for the https://phpstan.org/r/4241be28-13e8-49d0-bc6e-298a99f88df9.

Because defined/class_exists are covered by type specifying extensions their own resulting values are not specified so they can't be trivially inherited.

I tried to always add the handleDefaultTruthyOrFalseyContext() but that leads to infinite recursion in TypeSpecifyingFunctionsDynamicReturnTypeExtension in the general case. So I'd like to add (proper) support for the other functions separately and at least get this case working :)

Thank you!