Hi, I don't understand this:

looks like there is no validation at all of the value itself

What's the point then? I'd definitely want the validation.

Actually, I just checked what is_callable() does and it looks like it creates an intersection of CallableType and StringType: https://phpstan.org/r/4321ed59-36f6-4ee3-aad9-30da2a08c367

So we can scratch the new whole CallableStringType class and just work with the intersection...

So we can scratch the new whole CallableStringType class

I did some testing (I'm not practical enough of how PHPStan internals works, so I'm having an hard time contributing), but changing the TypeNodeResolver to return UnionType([new StringType(), new CallableType()]) instead of a whole new type produces issues elsewhere, for example PHPDoc tag @param for parameter $str with type (callable)|string is not subtype of native type string. I'm sure it's possible to handle this and that I'm doing something wrong, but wouldn't be more simple to handle the callable-string with its own type like the class-string implementation?

You need to make callable-string basically an alias of callable&string, not callable|string. Which means using IntersectionType, not UnionType.

Thank you.

Uuum, thank you for merging the PR but I still had to push the commit with the additional tests of the TypeCombinatorTest class... I will open a new PR to add them

PR is a PR, you're always risking I'm gonna merge it unless it's a draft :)

When you're at it, a new NodeScopeResolver::testFileAsserts data provider with callable-string in PHPDoc and assertType('callable&string', $param) would also be nice.

you're always risking I'm gonna merge it unless it's a draft

Lesson learned 😄

When you're at it, a new NodeScopeResolver::testFileAsserts data provider with callable-string in PHPDoc and assertType('callable&string', $param) would also be nice.

Sure, will do 👍