The one test failure is a BC break for a non-@api method call. Should I make the message optional, or is the breakage acceptable?

@rvanvelzen I think it's fine. It's my fault to use non-@api calls 😄 I'll fix it there.

@canvural Maybe I suggested to you myself to use FunctionCallParametersCheck so I'm sorry about it :) There should be a way in Larastan to do it nicer, just an idea: allow custom rule developer to invoke their own virtual nodes. You could invoke a custom FuncCall node and the rules in PHPStan would pick it up themselves.

But for now, feel free to prepare a new Larastan release that requires PHPStan ^1.7 (after this PR is merged), we can then coordinate the release together :)

Or pass the extra argument to FunctionCallParametersCheck, ignore PHPStan error for now, release it (and not change the PHPStan requirements), and clean it up after 1.7 is releaased :)

@rvanvelzen Just one more thing - have you looked into the failures before the new check was behind a feature toggle?

• https://github.com/phpstan/phpstan-src/runs/6453862910?check_suite_focus=true
• https://github.com/phpstan/phpstan-src/runs/6453863040?check_suite_focus=true
• https://github.com/phpstan/phpstan-src/runs/6453863215?check_suite_focus=true
• https://github.com/phpstan/phpstan-src/runs/6453863498?check_suite_focus=true

It'd be good to fix them now since it's a valuable piece of feedback about the new check :)

@ondrejmirtes yeah, I fixed most of them in f3c5928. There's one left that I'll try to fix.

Thank you!

I went the optional way as that avoids all of the headaches: a114a3f