Problem/Motivation
Just a quick fix for one of the baseline errors found by phpstan.
Steps to reproduce
Its in the baseline If you review the class you'll see the class isn't included. This doesn't currently throw any errors or warnings because the code isn't actually used.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | interdiff_14-16.txt | 762 bytes | mrinalini9 |
| #16 | 3264145-16.patch | 1.25 KB | mrinalini9 |
| #14 | reroll_diff_3264145_7-14.txt | 1.45 KB | ankithashetty |
| #14 | 3264145-14.patch | 1.28 KB | ankithashetty |
| #5 | reroll_diff_3264145-1_3264145-5.txt | 1.21 KB | yogeshmpawar |
Comments
Comment #2
neclimdulComment #3
mondrakeFixes a reported PHPStan error
Comment #4
catchNeeds a re-roll, also not sure why we wouldn't remove the unexecuted code - could use a follow-up for that at least.
Comment #5
yogeshmpawarUpdated patch will reroll diff added.
Comment #6
mondrakePer #4, instead of adding the
use, we should be removing the code that is using the constant that must be dead if no error ensues. Or add a test if it is not dead.Comment #7
ravi.shankar commentedTried to address comment #6, please review.
Comment #8
longwaveRe #4/#6 The issue is that the method belongs to the parent interface and the test class must implement it, but the method isn't triggered by the test so the runtime error never occurs.
I think we should just add the missing use statement and move on, rather than forcing a test case for a method that does nothing except return NULL anyway; PHPStan has already caught the problem and will catch it again if we reintroduce the bug.
Comment #9
neclimdulYeah, #5 still applies and is the correct fix as the failure in #7 shows so moving back to NR.
Expanding on longwave's comment, its a mock so we wouldn't test it anyways. We shouldn't test a test, just fix it. :-D
Maybe a dive into the relevant line would provide some clarity to reviewers and committers about why its currently "working" and why #7 broke the change broke things.
The code parses cleanly now because a reference to an undefined class like this isn't a fatal error until they're referenced.
Example, the second call errors:
Output:
The call to
createConfigObjectprovides the collection argument (all core calls seem to) so the default value is never used and the code "works". However changing a optional parameter like in #7 makes the method incompatible so it _does_ cause an error. Or an error in php 8 and a warning in php 7 because php is weird but it's all the same since it won't pass for us. PHPstan here is just warning us "hey if you ever called this wrong it would break" and its right and we can just fix it for correctness.Final note, technically I guess we could replace the optional value with null and it would fix the warning and be correct. However, I don't think that makes as much since as matching the parent signature entirely even if the method always returns null.
Comment #10
mondrakeThank you for the explanations.
Comment #13
mondrakeComment #14
ankithashettyRerolled the patch in #7. Also replaced the optional value with
NULLincreateConfigObjectas suggested in #9.Thanks!
Comment #15
daffie commentedThis is the wrong change. The warning can be fixed by adding the use-statement
use Drupal\Core\Config\StorageInterface;. Now is the StorageInterface not know, it is not defined in the directory of the test. Just like comment #8 is saying.Comment #16
mrinalini9 commentedHi,
I have added the patch by addressing the suggestion in #15, please review it.
Thanks & Regards,
Mrinalini
Comment #17
longwaveThank you.
Comment #18
alexpottCommitted 5253862 and pushed to 10.1.x. Thanks!
Committed ad66289 and pushed to 10.0.x. Thanks!
Committed 5f5ea22 and pushed to 9.5.x. Thanks!
Committed 86f87e9 and pushed to 9.4.x. Thanks!