I really like how it's coming together :) After this one is merged, I also look forward to support for properties and methods besides parameter names :)

There's some work left to be done here, but it should be ready for review.

I'm not sure if the always true/false errors should pop up from these asserts - a function could very well narrow a type down without that being the only thing the function does. This could actually be handled by specifying types from conditional return types. I have a PR almost ready for that.

All that aside: I'll be on holiday for the next 2 weeks so I won't be able to spend much time on this. If you point out any issues I'll gladly work on them but I just don't know how quickly that will be. Thanks for understanding :)

I'm not sure if the always true/false errors should pop up from these asserts - a function could very well narrow a type down without that being the only thing the function does.

That's my worry as well but I'd like to see in practice if it's a real concern or not. In theory someone could write @phpstan-assert above functions that do other things as side effects as well, but maybe it doesn't happen in practice and it's still useful to report things like "this int is already an int".

It'd be nice to have these "impossible or always-true type checks" reported only in bleeding edge, but I'm not sure we can easily isolate these cases from the already existing ones in rules like ImpossibleCheckTypeFunctionCallRule etc.

This could actually be handled by specifying types from conditional return types. I have a PR almost ready for that.

I have no idea what you mean by that, so I'm intrigued to see it :)

All that aside: I'll be on holiday for the next 2 weeks so I won't be able to spend much time on this.

I hope you won't mind if we're going to postpone this feature for PHPStan 1.8. There's already a lot of stuff ready in PHPStan 1.7 (and it doesn't mean we can't release 1.8 immediately after the PHPDoc-based type narrowing is merged too) and I'd like to gather real-world feedback on it soon. Thank you for understanding.

Sure, it's absolutely fine to let this sit until after 1.7 is released :)

In theory someone could write @phpstan-assert above functions that do other things as side effects as well, but maybe it doesn't happen in practice and it's still useful to report things like "this int is already an int".

As far as i know this is the current behavior in psalm, which is why not all methods in webmozarts/assert have an @psalm-assert annotation.
So it would probably be best to mimic this behavior in PHPStan. And maybe it helps promote people to write smaller functions that only do 1 thing, either a side effect or a validation.

BTW Do you have plans to support this syntax? Thanks! @psalm-assert =ExpectedType $actual

What would that do? Does that mean $actual is optional/nullable?

Not necessarily for the initial implementation, but I do plan on adding that as well.

What would that do?

I have no idea, doesn't seem documented: https://psalm.dev/docs/annotating_code/adding_assertions/

/cc @orklah What does @psalm-assert =ExpectedType $actual do? And is there any other syntax to be aware of?

Those are equality assertions, though the documentation for it is hard to find: https://psalm.dev/annotating_code/assertion_syntax/

I believe this has become a bit too large and complex. I'd like to break it up into a few pieces to make it easier to reason about.

Feel free to do what you think is best 😊 My idea for reflection is that I'm not sure if I want it on ParametersAcceptor vs. MethodReflection/FunctionReflection. I think it fits the latter better.

this PR seems to implement phpstan/phpstan#7385, please include the demo https://phpstan.org/r/53ba9b04-685e-404c-ba77-a9616ca75ace code in the tests

BTW @rvanvelzen This one would be a great thing to finish :) My idea is that instead of ParametersAcceptorWithAsserts / FunctionVariant etc., the getAsserts() could be on ExtendedMethodReflection + FunctionReflection.