good point.

2) PHPStan\Rules\Comparison\ImpossibleCheckTypeFunctionCallRuleTest::testBug6788
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'
+'13: Call to function chdir() with non-empty-string will always evaluate to true.
+    💡 Because the type is coming from a PHPDoc, you can turn off this check by setting <fg=cyan>treatPhpDocTypesAsCertain: false</> in your <fg=cyan>%configurationFile%</>.
+15: Call to function chdir() with non-falsy-string will always evaluate to true.
+    💡 Because the type is coming from a PHPDoc, you can turn off this check by setting <fg=cyan>treatPhpDocTypesAsCertain: false</> in your <fg=cyan>%configurationFile%</>.
 '

the last commit is fixing cases like

<?php

namespace Bug4816;

use function PHPStan\Testing\assertType;

function (string $x): void {
	if (is_dir($x)) {
		assertType('true', is_dir($x));
	}
};

(so we don't regress 1eaef04)

my understanding is, that because this PR adds stubs with @phpstan-assert the specifier does no longer invoke handleDefaultTruthyOrFalseyContext in

and that the reason why my previous code sample did regress. After adding handleDefaultTruthyOrFalseyContext I can see other things regress though :).

@rvanvelzen could you give me a hand? why do we not invoke handleDefaultTruthyOrFalseyContext when taking the path thru specifyTypesFromAsserts. is this expected or an oversight?

btw: I noticed we also don't invoke handleDefaultTruthyOrFalseyContext when we take the path thru specifyTypesFromConditionalReturnType.

I had no idea that the assertion would actually assert the opposite if the condition is not met. This is very counter-intuitive for me.. I think the behavior with "=" should be the default and there should rather be another modifier to request the double behavior.