This looks impossible to review and properly document. Who don't we do it in smaller parts?

Also eliminating type casts/checks is probably task for separate PR (PHPStan should catch them).

Clean up type casting and checks like (bool) $flag or is_string($string) which are no longer needed.

Also eliminating type casts/checks is probably task for separate PR (PHPStan should catch them).

I just though about the same. Will double check if PHPStan can do that and will file a ticket otherwilse and attach it here.

It definitely does, but probably on higher level than we have.
IMO we should've first worked on level 7 and then on enabling scalar types, this way we may end up with fatal errors in uncovered code (100% coverage is a dream).

This looks impossible to review and properly document. Why don't we do it in smaller parts?

I'd better try to come up with a systems approach of reviewing what's already done then splitting it apart and then putting back together. It took me a week to make this change including almost one day full time, and I may not have that much time for additional coding.

IMO we should've first worked on level 7 and then on enabling scalar types, this way we may end up with fatal errors in uncovered code (100% coverage is a dream).

I'd better have the branch destabilized but with all the code changes in place instead of not doing anything. AFAIK, the work on a higher PHPStan level and enabling strict types was started long ago but wasn't finished.

With this approach, we can have more non-covered breakages reported by users of develop and add more test coverage based on that.

PHPStan level and enabling strict types was started long ago but wasn't finished.

Hmm, where? Maybe I just forgot.
Enabling strict types is separate task, not blocking scalar types or PHPStan level upgrade.

Hmm, where? Maybe I just forgot.

I meant #3260 and #2854.

Enabling strict types is separate task, not blocking scalar types

I see. I misread this:

IMO we should've first worked on level 7 and then on enabling scalar types

Possibly a good idea to have #2854 in first - would catch a lot of runtime errors due to type mismatch, if there are any left

Yea, we discussed that internally.