Problem/Motivation
Amongst the current issues found in the PHPStan level 1 baseline is: Access to an undefined property Foo\Bar::$baz.
This issue exists to fix all of those, except for the ones listed below.
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.
- Run PHPStan on level 1 and don't see the above issue any more, except for the following instances that are either a bit more complicated and are split off into separate issues, or are already handled elsewhere.
message: "#^Access to an undefined property Drupal\\\\Core\\\\TypedData\\\\TypedData\\:\\:\\$value\\.$#"
count: 2
path: lib/Drupal/Core/TypedData/TypedData.php
message: "#^Access to an undefined property Drupal\\\\Core\\\\Entity\\\\EntityDisplayBase\\:\\:\\$_serializedKeys\\.$#"
count: 2
path: lib/Drupal/Core/Entity/EntityDisplayBase.php
- Handled in #3419114: Convert FileTransferTest into a Kernel test
message: "#^Access to an undefined property Drupal\\\\Tests\\\\system\\\\Functional\\\\FileTransfer\\\\TestFileTransfer\\:\\:\\$connection\\.$#"
count: 5
path: modules/system/tests/src/Functional/FileTransfer/TestFileTransfer.php
Also not fixed are all nine suppressions for this error in lib/Drupal/Component/Diff/Engine/DiffEngine.php.
That class is already deprecated and will be removed in D11, after which the entries in the PHPStan baseline can also be removed.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3347502
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:
Comments
Comment #3
longwaveShould we consider adding DiffEngine to excludePaths?
Comment #4
spokjePondered about that myself.
Decided against it, because it's not really "visual" for the average user that the file is excluded.
If only PHPStan had something like
@phpstan-ignore-file...Anyway, that's just my personal opinion, happy to be convinced to go the excludePaths route :)
Comment #5
mondrakeI would suggest no. In D11 the file will be gone, anyway. In the meantime, any refactoring introducing more errors will be at least pointed out. That applies to any deprecated file, imho.
Comment #6
spokjeComment #7
spokjeComment #8
spokjeComment #9
spokjeComment #10
spokjeComment #13
spokjeComment #14
longwaveLots of places we can drop @var following #3238192: Allow omitting @var for strictly typed class properties
Comment #15
ankithashettyHello @longwave, noticed in #3238192: Allow omitting @var for strictly typed class properties that we can omit @var only for strictly typed class properties.
If we look at the
Proposed resolutionsection, it says "This type can not be represented in the PHP typesystem yet." to variables like@var int|string|NULLSo can we really remove
@varhere:Comment #16
longwaveAnywhere that we do declare the types on the following lines, we can remove @var, for example:
Not so sure about
as I think
|falseis only valid in PHP 8.2 and we need to support PHP 8.1.Comment #17
ankithashettyCan we create a new MR for
11.xinstead of changing the target branch in the existing MR?Comment #18
spokjeAh, wasn't aware you were working on this at the moment. Put MR back to 10.1.x.
Feel free to change whatever you need, I'll be leaving this one alone.
Comment #19
ankithashettyThanks! 🙂 Was just thinking about working on #14 suggestions.
Comment #20
ankithashettyIn MR !3775 (against
10.1.x), if the change is not as expected, we can just revert the latest commit.Comment #25
spokjeComment #28
spokjeComment #29
spokjeComment #31
quietone commentedComment #32
spokjeComment #33
smustgrave commentedSmall comments on the MR.
Comment #34
longwaveComment #35
smustgrave commentedBelieve all feedback for this one has been addressed
Comment #36
catchSaving credit. Needs a rebase.
Comment #37
longwaveRebased.
Comment #39
catchCommitted/pushed to 11.x, thanks!