More precise types after assignment when strict-types=0 #3965

staabm · 2025-04-28T15:49:51Z

Improve types on top of #3945 but for the non-strict-types case.

see https://phpstan.org/r/aa5d5753-eca2-4735-bebf-6479e1ab1f42

~~do you think we could remove nullability from the property-type in scope, as the method we call returns a native non-nullable type, even if strict-types=0...?~~

closes phpstan/phpstan#12946
closes phpstan/phpstan#12940
closes phpstan/phpstan#12950
closes phpstan/phpstan#12947

phpstan-bot · 2025-04-28T15:58:22Z

This pull request has been marked as ready for review.

ondrejmirtes · 2025-04-28T19:30:52Z

I don't get why this is needed and why the current logic from #3945 doesn't already work for that. Can you explain please?

staabm · 2025-04-28T19:47:57Z

~~The logic implemented in the already merged PR only takes the native type from the assignment, when one of the property-native-flattened types is a super-type of the assigment type.~~

In the given example the native type of the property is not a super-type of the assigment. Thats why the current logic doesn't take effect. Since we are in non-strict type-land the else-if also doesn't narrow the types.

~~New: as a last resort we therefore only use the native knowledge about non-nullability of the assignment, to narrow the property type in scope.~~

~~The example only works because of phpdoc types (and these types are not expressable with native types - aka param-out in this case; similar thing could happen in conditional return types)~~

staabm · 2025-04-29T06:55:39Z

scratch the previous comment.

before #3945 we always assigned a type, and since #3945 we no longer do so. we are missing a ELSE case

phpstan-bot · 2025-04-29T07:14:24Z

This pull request has been marked as ready for review.

src/Analyser/NodeScopeResolver.php

staabm · 2025-04-29T07:59:18Z

tests/PHPStan/Analyser/nsrt/bug-12393b.php

@@ -0,0 +1,145 @@
+<?php declare(strict_types = 0);


copied the test 12393 and changed only the strict_types to 0

src/Analyser/NodeScopeResolver.php

ondrejmirtes · 2025-04-29T10:43:55Z

I just forcepushed here how the code makes sense to me. We just need to fix the failing tests 😂

staabm · 2025-04-29T10:50:56Z

thanks for the hints.. I will look into the errors after a lunch break

staabm · 2025-04-29T10:53:52Z

We just need to fix the failing tests 😂

do you mean adjusting test expectations or fixing the underlying bugs?

ondrejmirtes · 2025-04-29T11:23:08Z

Fix the bugs

staabm · 2025-04-29T12:59:45Z

ready for another review. added loads of new tests

ondrejmirtes · 2025-04-29T13:11:24Z

I didn't mean you to start changing the toCoerced... method. It we do that, we need to do it right.

What I meant right now is to slightly adjust what the "else" branch in NodeScopeResolver does after my force-push.

It's up to you 😊

staabm · 2025-04-29T13:19:48Z

What I meant right now is to slightly adjust what the "else" branch in NodeScopeResolver does after my force-push.

I don't see a way how a slight change can fullfill the tests

It we do that, we need to do it right.

could you give me an idea whats "wrong" in the current PR?
do you see errors, or do you mean more precise results - like non-empty-string -> int cannot be 0 ..?

ondrejmirtes

This looks promising. But you haven't touched toCoercedArgumentType in some types. For example in ArrayTypeTrait, HasOffset*Type, accessory array types, NullType, ObjectType (Stringable object can be passed to string imho), ObjectTypeTrait.

For example VoidType should do (new NullType)->toCoercedArgumentType($strictTypes).

staabm · 2025-05-01T06:56:18Z

thanks for the hints.

I have added support for Stringable objects and callable types.
callables are interessting because they can be coerced to array/string in weak and strict mode
https://3v4l.org/WJ8NW

intentionally I did not add array types, as I don't find a example in which they can be coerced.
I have added tests for the cases I could think of, but these did not need adjustments in one of the toCoercedArgumentType Type methods.

I have also added tests for void type and these also did not need adjustments in toCoercedArgumentType Type methods.

ondrejmirtes · 2025-05-01T07:00:13Z

@staabm These coercions are described on PHP website. See the links near the bottom at https://www.php.net/manual/en/language.types.type-juggling.php

Converting to boolean
Converting to integer
Converting to float
Converting to string
Converting to array
Converting to object
Converting to resource
Converting to NULL

I'm especially worried about those array accessory types because they just return this, I'm not sure what would happen for example when you have non-empty-array and try to assign it into integer, whethey it'd work properly or not.

staabm · 2025-05-01T07:09:23Z

I think the conversion rules on these manual pages describe what happens on explicit casts.
property assigments doen't apply the same rules.

see e.g. https://3v4l.org/H5XnR while you can cast a 1 to array, you cannot assign 1 to a array typed property

for example when you have non-empty-array and try to assign it into integer, whethey it'd work properly or not.

just added tests for the mentioned cases

staabm · 2025-05-01T07:18:25Z

As I understand it, implicit conversion only happens for the listed scalar types

staabm · 2025-05-01T07:35:09Z

tests/PHPStan/Analyser/nsrt/bug-12393b.php

+        assertType('null', $this->foo);
+
+        $this->fooNonNull = $this->returnVoid();
+        assertType('int|null', $this->foo); // should be *ERROR*


I think this is a bug regarding void-to-null transformation which should be fixed in a followup PR

its a rare edge case

ondrejmirtes · 2025-05-01T07:43:06Z

Oh interesting, didn't know about that.

staabm · 2025-05-01T07:45:12Z

tests/PHPStan/Analyser/nsrt/bug-12393.php

+	private string $foo;
+
+	public function doFoo(callable $foo): void {
+		$this->foo = $foo; // PHPStorm wrongly reports an error on this line


opened a PHPStorm bug: https://youtrack.jetbrains.com/issue/WI-81263/Property-must-be-of-type-string-callable-provided-false-positive

To be fair PHPStan also reports an error for that (which is correct, we mostly don't differentiate between strict_types 1 or 0 in Type::accepts().

ondrejmirtes · 2025-05-01T09:14:47Z

src/Type/ObjectType.php

@@ -706,6 +706,10 @@ public function toArrayKey(): Type

 	public function toCoercedArgumentType(bool $strictTypes): Type
 	{
+		if (!$strictTypes) {
+			return TypeCombinator::union($this, $this->toString());


If the object isn't a Stringable, this should just return $this. But instead it will return ErrorType.

Also I'm not sure what happens with BcMath\Number in strict_types=1 or 0.

added tests with links to 3v4l.org

ondrejmirtes · 2025-05-01T20:42:37Z

Alright, I'm really excited about this, let's try it out!

VincentLanglet · 2025-05-02T21:44:57Z

Hi @staabm,

I just saw this and I have some question about this change.

Why https://phpstan.org/r/908e9206-cf9a-4148-8e3b-18805be3ab1a is still reported in strict-types 0 but
https://phpstan.org/r/5075f3d0-f6c6-42ed-bf20-7292529cd705 is not reported anymore in strict-types 0 (but still in strict-types 1).
When I have an existing codebase I want to migrate from strict_types 0 to 1, I generally rely on PHPStan to prevent futur error. If I understand this PR, it's now not possible now since some error are not reported anymore. What about an option to tell PHPStan to keep consider files like strict_types=1 even if they currently are strict_types=0 (and this option could be activated in strict-rules) ?

staabm · 2025-05-03T06:14:05Z

Huhu

The PR is about type inference, meaning PHPStan better know when/which types flow thru the code. It does not change the rules when errors are reported.
(Which type accepts which)

Regarding BcMath\Number. it behaves like that because the php runtime only errors when strict_types=1, but for strict_types=0 it's legale to assign a object which implements __toString to a string.

I don't know whether this makes sense. In case you want strict_types=1 you can declare it and work on the errors. ondrey might have a clear opinion on it

staabm · 2025-05-03T06:23:17Z

The 2 different modes have different characteristics and not necessarily everyone want to migrate from weak to strict.

I have recently seen discussions of php-src devs whether a new mode should be implemented which is a mix of the 2 existing ones, as both have some advantages

ondrejmirtes · 2025-05-03T07:23:09Z

@VincentLanglet This behaviour didn't change with this PR. If PHPStan reports errors in the same situations where PHP reports TypeError, it's correct.

staabm mentioned this pull request Apr 28, 2025

Fix imprecise types after assignment when strict-types=1 #3945

Merged

staabm marked this pull request as ready for review April 28, 2025 15:58

staabm marked this pull request as draft April 29, 2025 05:27

staabm mentioned this pull request Apr 29, 2025

Memoization property on class now incorrectly treated as always null after set phpstan/phpstan#12946

Closed

clxmstaab force-pushed the non-null branch from 7275135 to f66ec0c Compare April 29, 2025 06:53

clxmstaab force-pushed the non-null branch from 9f2df2c to 3d327a8 Compare April 29, 2025 07:05

staabm marked this pull request as ready for review April 29, 2025 07:14

staabm commented Apr 29, 2025

View reviewed changes

src/Analyser/NodeScopeResolver.php Show resolved Hide resolved

staabm commented Apr 29, 2025

View reviewed changes

ondrejmirtes requested changes Apr 29, 2025

View reviewed changes

src/Analyser/NodeScopeResolver.php Show resolved Hide resolved

ondrejmirtes force-pushed the non-null branch from 48fad99 to 4f2ce34 Compare April 29, 2025 10:43

clxmstaab force-pushed the non-null branch from a243baa to 6a56c6f Compare April 29, 2025 11:32

staabm mentioned this pull request Apr 29, 2025

non-falsy-string cannot be converted to 0 #3971

Merged

staabm force-pushed the non-null branch from 2b6f0fe to d6d3e15 Compare April 29, 2025 17:11

This was referenced Apr 30, 2025

method.nonObject does not recognize object creation since 2.1.13 phpstan/phpstan#12940

Closed

PHPStan is not respecting PHPDoc return types on static methods phpstan/phpstan#12950

Closed

staabm force-pushed the non-null branch from 95c7903 to b7f8815 Compare April 30, 2025 08:22

ondrejmirtes requested changes Apr 30, 2025

View reviewed changes

staabm added 7 commits May 1, 2025 08:13

test array accessories and HasOffset*Type

76e1258

support Stringable objects

4bb13d8

test mix of array value types

d338a47

fix has_method('__toString') coercison

9d19f30

suport callable arrays

0560ae2

test void can be null

113c7d4

support callable as string

3d34649

staabm force-pushed the non-null branch from b7f8815 to 3d34649 Compare May 1, 2025 06:49

fix callable strings

c16582a

test array-accessory to X

c6db4e7

added strict-type test-variants for callable array/string

61e0eea

staabm commented May 1, 2025

View reviewed changes

ondrejmirtes requested changes May 1, 2025

View reviewed changes

staabm added 4 commits May 1, 2025 14:02

test not stringable and bcmath

a8abeae

Update bug-12393b.php

016d44a

test stringable in strict-types

95186fe

separated php 8.4 tests

b14719a

ondrejmirtes merged commit ea7072c into phpstan:2.1.x May 1, 2025
415 of 417 checks passed

staabm deleted the non-null branch May 2, 2025 05:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

More precise types after assignment when strict-types=0 #3965

More precise types after assignment when strict-types=0 #3965

staabm commented Apr 28, 2025 •

edited

Loading

phpstan-bot commented Apr 28, 2025

ondrejmirtes commented Apr 28, 2025

staabm commented Apr 28, 2025 •

edited

Loading

staabm commented Apr 29, 2025

phpstan-bot commented Apr 29, 2025

staabm Apr 29, 2025

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025

staabm commented Apr 29, 2025

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025 •

edited

Loading

ondrejmirtes left a comment

staabm commented May 1, 2025

ondrejmirtes commented May 1, 2025

staabm commented May 1, 2025 •

edited

Loading

staabm commented May 1, 2025

staabm May 1, 2025 •

edited

Loading

ondrejmirtes commented May 1, 2025

staabm May 1, 2025

ondrejmirtes May 1, 2025

ondrejmirtes May 1, 2025

staabm May 1, 2025

ondrejmirtes commented May 1, 2025

VincentLanglet commented May 2, 2025

staabm commented May 3, 2025 •

edited

Loading

staabm commented May 3, 2025

ondrejmirtes commented May 3, 2025

More precise types after assignment when strict-types=0 #3965

More precise types after assignment when strict-types=0 #3965

Conversation

staabm commented Apr 28, 2025 • edited Loading

phpstan-bot commented Apr 28, 2025

ondrejmirtes commented Apr 28, 2025

staabm commented Apr 28, 2025 • edited Loading

staabm commented Apr 29, 2025

phpstan-bot commented Apr 29, 2025

staabm Apr 29, 2025

Choose a reason for hiding this comment

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025

staabm commented Apr 29, 2025

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025

ondrejmirtes commented Apr 29, 2025

staabm commented Apr 29, 2025 • edited Loading

ondrejmirtes left a comment

Choose a reason for hiding this comment

staabm commented May 1, 2025

ondrejmirtes commented May 1, 2025

staabm commented May 1, 2025 • edited Loading

staabm commented May 1, 2025

staabm May 1, 2025 • edited Loading

Choose a reason for hiding this comment

ondrejmirtes commented May 1, 2025

staabm May 1, 2025

Choose a reason for hiding this comment

ondrejmirtes May 1, 2025

Choose a reason for hiding this comment

ondrejmirtes May 1, 2025

Choose a reason for hiding this comment

staabm May 1, 2025

Choose a reason for hiding this comment

ondrejmirtes commented May 1, 2025

VincentLanglet commented May 2, 2025

staabm commented May 3, 2025 • edited Loading

staabm commented May 3, 2025

ondrejmirtes commented May 3, 2025

staabm commented Apr 28, 2025 •

edited

Loading

staabm commented Apr 28, 2025 •

edited

Loading

staabm commented Apr 29, 2025 •

edited

Loading

staabm commented May 1, 2025 •

edited

Loading

staabm May 1, 2025 •

edited

Loading

staabm commented May 3, 2025 •

edited

Loading