Problem/Motivation
Amongst the current suppressions found in the PHPStan level 1 baseline is: Variable $foo might not be defined..
This issue exists to fix all of those caused by non-exhaustive switch statements. See https://github.com/phpstan/phpstan/issues/7521#issuecomment-1164581820
Steps to reproduce
- Run PHPStan on level 1 and see the above issue amongst all others.
Proposed resolution
- Solve all of the reported issues for the above mentioned.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3353918
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3353918-fix-phpstan-l1
changes, plain diff MR !3823
Comments
Comment #3
spokjeComment #4
spokjeComment #5
smustgrave commentedDon't mind marking but is the plan to tackle the others slowly? Seems to be 126 other instances in the baseline file.
Comment #6
spokjeThat's at least my plan. Can't see a patch/MR with 126+ changes which have mostly unrelated causes being reviewable.
So IMHO it's better to "nibble" at that massive number by grouping some by cause.
Granted: There's no way to ensure we get them all per issue, since it's a manual process and some can be missed.
But they will stand out when the number drops to something reasonable, and we can them identify and fix them easily.
Comment #7
spokjeRebased after weirdly TestBot didn't kick this back down to NW after failing to merge since 21 Apr 2023 at 13:56 CEST.
.
Comment #8
mondrakeAdding a parent meta, to cope with #5 and #6.
Comment #9
mondrakesorry to push this back, just a couple of points
Comment #10
spokjeThanks @mondrake, fixed one thread, left a comment in the other.
Comment #11
mondrakethanks, two nits but do not stop RTBC
Comment #12
spokjeThanks @mondrake agiain, think/hope i picked yer nits.
Comment #14
kim.pepperNeeds a rebase on 11.x
Comment #15
spokjeRebased
Comment #16
longwaveOverall I like this change as it removes a lot of verbosity, but in some cases perhaps we have gone a bit too far in making the code very dense and hard to understand.
Comment #17
spokjeThanks @longwave, resolved all threads.
Comment #18
longwaveOne more simplification, and I think a bug has been introduced.
Comment #20
rpayanmPlease review.
Comment #21
smustgrave commentedPoints from threads appear to have been addressed.
Comment #22
spokjeAdded some remarks (just to show I'm a grumpy old man ;)
Back to NR for those.
Comment #23
longwaveComment #24
spokjeResolved last open thread and rebased.
Comment #25
smustgrave commentedAll threads appear to be resolved.
Thanks @Spokje!
Comment #26
longwavematch()throwsUnhandledMatchErrorif no cases are matched, and I was wondering if this could somehow be a behaviour change in the asset groupers. I don't think there is anything stopping someone declaring an unhandled type - the default isfile, andexternalis supposedly the only other value, but at the moment it looks like this will cause either a warning or perhaps just a misgrouping, and this behaviour will change now?I also am a bit confused about this in
AssetResolver::getJsAssets(), I couldn't see if or how typesettingis somehow handled elsewhere:I don't have any such concerns about the other issues, it seems OK for those to trigger errors if they try to match unexpected values.
Comment #27
longwaveJsCollectionRenderer throws a LogicException if it's not a file, external or setting type, but I still don't see how settings don't end up in the grouper. It feels like these should be refactored to be value objects instead of arrays with a type key...
Comment #28
longwaveJsCollectionRenderer throws a LogicException if it's not a file, external or setting type, but I still don't see how settings don't end up in the grouper. It feels like these assets should be refactored to be value objects instead of arrays with a type key...
Comment #29
smustgrave commentedFor #27 if I'm reading that correctly.
Comment #30
spokje@longwave:
It took me a while to wrap my head around your comments, but the whole behaviour in the asset groupers is weird/bad/unwanted/name-your-posion.
If
typeis notfilenorexternal, it looks like, besides throwing a notice (Undefined variable $group_keys) when the asset is the first in theassets-array, the asset at least gets grouped with the asset before it.So at the very least, we need a followup to sort that out.
I can't imagine there being much non-
file/externalassets around in the wild, but the change in the current MR would indeed break those.Let's sort both
CssCollectionGrouperandJsCollectionGrouperin the follow-up issue.Comment #31
spokjeWe _could_ add a
defaultto the currentswitchstatements inCssCollectionGrouperandJsCollectionGrouperwhere we throw a deprecation if thetypeis neitherfilenorexternalto warn people early.But that could also be better to do in the follow-up?
Comment #32
longwaveRebased, let's revive this and try to get these cases fixed, the asset grouping ones can be fixed elsewhere.
Comment #33
mondrakeSeems no open points now.
Comment #36
alexpottDiscussed with @longwave, we agreed that UnhandledMatchError is better than the current behaviour of warning a variable is not set and then breaking in odd ways.
Merged back to 10.3.x - nice work everyone.
Comment #37
alexpott