Skip to content

Retain non-variable expression types in closure#1929

Merged
ondrejmirtes merged 1 commit into
phpstan:1.9.xfrom
rvanvelzen:bug-8205
Nov 1, 2022
Merged

Retain non-variable expression types in closure#1929
ondrejmirtes merged 1 commit into
phpstan:1.9.xfrom
rvanvelzen:bug-8205

Conversation

@rvanvelzen

Copy link
Copy Markdown
Contributor

@herndlm

herndlm commented Oct 27, 2022

Copy link
Copy Markdown
Contributor

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

@rvanvelzen

Copy link
Copy Markdown
Contributor Author

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.

@ondrejmirtes ondrejmirtes left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't the right solution. You don't know when the callable will be called so it's correct to invalidate $this->foo even if it was checked against null outside of the closure - it can be null again inside.

Function_exists() is special in this regard, because there's no way to unload a function in PHP, so it should "survive" when entering closure.

@rvanvelzen

Copy link
Copy Markdown
Contributor Author

$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

@ondrejmirtes

Copy link
Copy Markdown
Member

Please see: #1934 (comment)

@ondrejmirtes

Copy link
Copy Markdown
Member

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)

@rajyan

rajyan commented Oct 29, 2022

Copy link
Copy Markdown
Contributor

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.

@rvanvelzen

Copy link
Copy Markdown
Contributor Author

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 :)

@ondrejmirtes ondrejmirtes merged commit 2757b8d into phpstan:1.9.x Nov 1, 2022
@ondrejmirtes

Copy link
Copy Markdown
Member

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

function_exists outside of callback does not keep knowledge of function existing

4 participants