-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
feat: resolve phpstan errors method.nonObject in tests for Types #7253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.4.x
Are you sure you want to change the base?
Changes from all commits
b06a2ae
1abb899
9e6dffa
87cc91c
c3c9416
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,6 +33,7 @@ public function testDateConvertsToPHPValue(): void | |
|
|
||
| public function testDateResetsNonDatePartsToZeroUnixTimeValues(): void | ||
| { | ||
| /** @var DateTime $date */ | ||
| $date = $this->type->convertToPHPValue('1985-09-01', $this->platform); | ||
|
Comment on lines
+36
to
37
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem here is that PHPStan does not understand the type of
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which I see meanwhile I fix this, it is src/Types/Type.php is an abstract class. And the problem using convertToPHPValue in that class, it is that return as mixed, but other clases like tests/Types/TimeTest.php are overriding the abstract return, for example with ?DateTime In src/Types/VarDateTimeImmutableType.php is ?DateTimeImmutable. So I think that the problem is that the method should be abtract in src/Types/Type.php and no contain body That means which src/Types/TypeWithConstructor.php should have also the method to avoid: Line TypeWithConstructor.php :10 Non-abstract class Doctrine\DBAL\Tests\Types\TypeWithConstructor contains abstract method convertToPHPValue() from class I made that changes at 1abb899 So phpstan is a static analyzer, it doesn't execute code or infer types based on which concrete subclass is instantiated at runtime. In TimeTest.php, $this->type is declared as Type (the base class), even though it's initialized as new TimeType(). When you call $this->type->convertToPHPValue('01:23:34', $this->platform), phpstan sees the return as mixed because that's what the base class declares. It doesn't "know" that $this->type is actually a TimeType instance that returns ?DateTime. So I understan which this is a limitation of static analysis: it prioritizes declared types over inferred runtime types to avoid false positives. And level 9 requires explicit types where ambiguity exists, even if the code is "obviously" correct at runtime. Other options that I can try:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
No. A subclass may narrow the return type of a method. This has nothing to do with the parent class/method being abstract or not.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The problem is not with the tests. The problem is with the types. Here, one test covers one type, so we have a luxury of parameterizing the tests by guessing what PHP types the given data type operates. But users interact with multiple types at a time – what are they going to do? The test should reflect the intended experience of the consumer, and that's not the experience we intend for. Instead of tests, types should be parameterized, but that's likely a Pandora's box (our types are a mix of database types, user-defined types, mapping from PHP types to database data types, etc.). |
||
|
|
||
| self::assertEquals('00:00:00', $date->format('H:i:s')); | ||
|
|
@@ -42,10 +43,12 @@ public function testDateRestsSummerTimeAffection(): void | |
| { | ||
| date_default_timezone_set('Europe/Berlin'); | ||
|
|
||
| /** @var DateTime $date */ | ||
| $date = $this->type->convertToPHPValue('2009-08-01', $this->platform); | ||
| self::assertEquals('00:00:00', $date->format('H:i:s')); | ||
| self::assertEquals('2009-08-01', $date->format('Y-m-d')); | ||
|
|
||
| /** @var DateTime $date */ | ||
| $date = $this->type->convertToPHPValue('2009-11-01', $this->platform); | ||
| self::assertEquals('00:00:00', $date->format('H:i:s')); | ||
| self::assertEquals('2009-11-01', $date->format('Y-m-d')); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a breaking change. We can't do this in a minor release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, we use the phpstan annotations for the minor only? and the other solution for a major?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that this method needs to be abstract, tbh. And no, I'm not planning major releases for the sake of satisfying a static analyser.