Resolve issues exposed by PHPStan Strict

There are about 8 or so issues I'll create, one for each error type.

An issue is to come about including PHPStan strict, with all configurable options set to off (the issues resolved here are not configurable).

This will allow us to resolve the strict issues one by one, in a similar manner to PHPStan levels.

The amount of problems exposed by strict is very very large (compared to these sub-issues), and not otherwise covered by PHPStan levels.

My 2 cents.

I've just run analysis with level 0 and no baseline - we still have 230+ issues there, over 2 years since the introduction of PHPStan. We discussed to introduce level 2 during the beta window of D11.0, and missed that. No action happened since then, we are in beta window for D11.1 now and will therefore miss that chance here again.

Recently since the addition of the function/method return type check rules (I think they're level 5 or 6 rules, normally), the baseline grew so big that lots of MRs require continuous rebasing to catch up with its changes (can you imagine if we were bumping to level 9 as discussed somewhere else?).

IMHO before looking at adding more rules (phpstan-strict-rules has, btw, 'opinionated' rules, that will require discussion to use or not and possibly have coding standards impacts), we should still work on basics, cleanup existing baseline, bump one level at a time, reiterate. And there's very little focus on that to be honest.

Do we need the package yet? The docs say that if you turn off all the rules, it still turns on stricter options in PHPStan itself; can't we just turn those on individually where required?

https://phpstan.org/config-reference#stricter-analysis

FWIW I am in favour of enabling checkFunctionNameCase but maybe not checkExplicitMixedMissingReturn yet, for example.

I temporarily postponed the 4 child issues, if I'm wrong please let me know. I want to make sure that those changes would be accepted without a rule in place.

Example 🐛 Typo in WidgetInterface.php Active was postponed pending a rule.

Regretfully it seems I havnt made my point about the strict project

I could just as well removal all mentions of the strict project, and these issues would be just as valid.

We don’t need to include or evaluate IF we should use strict. Thats not what these issues are about.

A separate discussion on including strict is necessary, but doesn’t need to get in the way of these handful of things.

with level 0 and no baseline - we still have 230+ issues there, over 2 years since the introduction of PHPStan. We discussed to introduce level 2 during the beta window of D11.0, and missed that. No action happened since then, we are in beta window for D11.1 now and will therefore miss that chance here again.

[...] And there's very little focus on that to be honest.

There is nothing affecting or distracting any of the existing PHPstan work. The things that strict covers can be worked alongside normal PHPStan levels: all about defensive coding style. Perhaps regarding core PHPStan levels, its worth having discussions in #phpstan about accellerating/resolving your concerns.

Do we need the package yet? The docs say that if you turn off all the rules, it still turns on stricter options in PHPStan itself; can't we just turn those on individually where required?

Yes, that's it what this batch of issues are addressing. These related issues are not the real strict rules. It’s moreso things that need to be tightened up before the real rules can be applied.

Just looking at the changes in the related issues, they are quite obvious. We don't yet need tooling to enforce them from re-occurring.

IMHO before looking at adding more rules (phpstan-strict-rules has, btw, 'opinionated' rules, that will require discussion to use or not and possibly have coding standards impacts),

And just some 2c, most of my contrib and private projects use strict. From experience, nothing needs to happen with linting ("coding standards/style"). Running strict properly does change the way you write code, for the better, and this isn't something thats enforced by the Drupal Coder notion of linting.

I've created 🌱 [meta] Introduce PHPStan Strict Rules Active for discussion about introducing PHPStan strict rules to Drupal core.

Going to say if these get merged then issues like https://www.drupal.org/project/drupal/issues/3486996 🐛 Typo in WidgetInterface.php Active should be unpostponed too

And just FYI I'm not arguing for or against any of these, but am arguing for consistency. If we postpone issues pending a rule being added then we should do that for all. If we allow these in then any of those issues I believe should be un-postponed and eligible to be merged too.