- 
  Notifications
 You must be signed in to change notification settings 
- Fork 545
Implement TypeSpecifierContext->getReturnType() #3881
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
Conversation
b51334d to
 2e88651  
 Compare
 
 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.
drop the caching, as context now contains an additional Type (state)
on my machine this did not make a difference in performance
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.
atm I whitelisted the cases which I dropped above to keep my sanity.
I feel we can drop it after we removed the hard-coded case list and moved the logic into extensions
the case failling in webmozart-assert is effectively
<?php
declare(strict_types=1);
class HelloWorld
{
	public function sayHello($m): void
	{
		\PHPStan\dumpType(
			is_string($m)
			&& strlen($m) >= 1
			&& strlen($m) <= 0
		);
	}
}
not sure what todo with it atm.
edit: fixed with 19749e8
fd864ad to
 23ec354  
 Compare
 
 debugging some more, I think more precisely the problem is here:
<?php
function sayHello(string $m): void
{
	if (strlen($m) >= 1) {
		if (strlen($m) <= 0) {
			\PHPStan\dumpType(
				$m
			);
		}
	}
}
it dumps non-empty-string instead of *NEVER*
edit: fixed with 19749e8
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.
we might move this into TypeSpecifier instead.
when $callType instanceof NeverType turn all non-by-ref-args into *NEVER*.
not sure its required though.
9b9a23e to
 19749e8  
 Compare
 
 This pull request has been marked as ready for review.
//cc @herndlm
daf1b02 to
 99f1b0a  
 Compare
 
 99f1b0a to
 3212ca9  
 Compare
 
 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.
In the future we could use this new api also for == and === not just < I think.
Yeah, this works, but I'd like to "burn more bridges" in the first PR about this change. I don't mean "breaking backward compatibility", but what I mean is to use the new code path as much as possible.
- TypeSpecifierContext should be created with the return type. So the constructor should accept ?Type, not?int $value.
- We probably don't need the constants with bitmasks at all. The createTrue etc. methods should simply create the object with a type that makes sense and continues to be correct.
- The negate method is tricky. Maybe we need to create the object with both the "if" path type and the "else" path type.
I use this approach often. It forces the code to be correct and generally uncovers any flaws about the changes 😊
843bdbf to
 5ae6cc0  
 Compare
 
 
Uh oh!
There was an error while loading. Please reload this page.
trying a minimal approach to see whether the idea works as a whole
for expression like
if (doFoo() > 0)we want to pass the context specific return-type information into type-specifying extensions so they can decide not just on true/truethy/false/falsy but also on "remaining return type values" (e.g. preg_match returns
0|1|false)this should help to reduce the number of hardcoded hacks within the TypeSpecifier und move over some cases into extensions (which also allows 3rd party extensions todo similar things, as they can't hard-code hack the TypeSpecifier)
ondrej quoted: