Introduce uppercase-string

[pmjones]

This PR introduces uppercase-string in all places where lowercase-string is recognized, except for SprintfFunctionDynamicReturnTypeExtension.

The omission is because sprintf() format strings cannot be typed reliably as uppercase-string because most of the formatting specifiers are lowercase. For example, the format string 'FOO %s BAR' is treated as a plain string rather than uppercase-string, because %s is lowercase (even though it might represent an uppercase string).

It appears that lowercase-string exhibits similar behavior. For example, consider the format string foo %F. It formats as the lowercase string 'foo' and a non-locale-aware float; the returned string will be the same after strtolower(), so it should be valid as a lowercase-string.

However, in nsrt/lowercase-string-sprintf.php, if you add assertType('lowercase-string', sprintf('foo %F', $lowercase));, it will fail with:

Expected: lowercase-string Actual: non-falsy-string 

That's because %F is uppercase, even though it represents a float.

If you consider these to be problems, they might be resolved by adding a new type, printf-string, that can ignore the formatting specifiers when determining isLowercase() and isUppercase(), but I imagine that would have rather broad implcations.

Let me know how you'd like to proceed.

[ondrejmirtes]

This is very complete and very nice, thank you! Just one thing I noticed.

[ondrejmirtes]

One more thing - Windows tests are failing https://github.com/phpstan/phpstan-src/actions/runs/11749776276/job/32736693637?pr=3613

[pmjones]

One more thing - Windows tests are failing https://github.com/phpstan/phpstan-src/actions/runs/11749776276/job/32736693637?pr=3613

Yes; it's related to this change where two reasons are given instead of one, and the PHP_EOL between them causes the Windows failures.

After thinking about it some more, I believe it should remain as one reason (not two) and am trying to track down where the second reason is coming from. Any help there would be appreciated!

[ondrejmirtes]

I found a few more things.

[ondrejmirtes]

After you rebase on top of 1.12.x with this commit ccfb4ab, the rule error tip should appear only once.

[pmjones]

After you rebase on top of 1.12.x with this commit ccfb4ab, the rule error tip should appear only once.

That did the trick; thanks!

[VincentLanglet]

This PR should be copied too. #3510

IntegerRangeType::toString and IntegerType::toString are both lowercase-string and uppercase-string.

And a whole reflection on lowercase-string&uppercase-string seems needed.

Cause if this intersection is lost the current code

/** @param lowercase-string $string */ public function acceptsOnlyLowercase($string) {} /** @var int $int */ $int = ...; acceptsOnlyLowercase((string) $int); // Will report an error 

and doesn't actually cf
https://phpstan.org/r/e722e920-af05-4c7b-8290-1205df68c4f8

[ondrejmirtes]

In this case we need to verify that TypeCombinator::intersect() of both lowercase-string and uppercase-string leads to expected result. And both types need to tell that it's possible it can be the other too.

Should be done in TypeCombinatorTest.

[VincentLanglet]

The current ToDo-list seems to be:

• This comment need to be addressed
  https://github.com/phpstan/phpstan-src/pull/3613/files#r1835752042

• Same for https://github.com/phpstan/phpstan-src/pull/3613/files#r1835752521

• appendAccessoryCasedStringTypes need to be changed.

• lowercase-string|uppercase-string should be simplified as string

• We need to understand why parse_url/trim doesn't produce the expected behavior.

[VincentLanglet]

We also need lowercase-string|uppercase-string to be simplified to string

[pmjones]

@VincentLanglet "This PR should be copied too. https://github.com/phpstan/phpstan-src/pull/3510"

That one is merged into 1.12.x, and I have rebased since that PR, so I think it has been included now. Let me know if I am mistaken.

[pmjones]

@VincentLanglet "We also need lowercase-string|uppercase-string to be simplified to string" -- I admit I do not know where to accomplish this. Hints/tips?

[VincentLanglet]

@VincentLanglet "This PR should be copied too. https://github.com/phpstan/phpstan-src/pull/3510"

That one is merged into 1.12.x, and I have rebased since that PR, so I think it has been included now. Let me know if I am mistaken.

You need to update

• IntegerType::toString, it returns

return new IntersectionType([	new StringType(),	new AccessoryLowercaseStringType(),	new AccessoryUppercaseStringType(),	new AccessoryNumericStringType(),	]); 

• IntegerRangeType::toString, it returns

$finiteTypes = $this->getFiniteTypes();	if ($finiteTypes !== []) {	return TypeCombinator::union(...$finiteTypes)->toString();	}	$isZero = (new ConstantIntegerType(0))->isSuperTypeOf($this);	if ($isZero->no()) {	return new IntersectionType([	new StringType(),	new AccessoryLowercaseStringType(), new AccessoryUppercaseStringType(),	new AccessoryNumericStringType(),	new AccessoryNonFalsyStringType(),	]);	}	return new IntersectionType([	new StringType(),	new AccessoryLowercaseStringType(),	new AccessoryUppercaseStringType(),	new AccessoryNumericStringType(),	]); 

[VincentLanglet]

@VincentLanglet "We also need lowercase-string|uppercase-string to be simplified to string" -- I admit I do not know where to accomplish this. Hints/tips?

Might need to be validated with @ondrejmirtes, but I think it's in TypeCombinator::union or TypeCombinator::compareTypesInUnion

But it seems not easy to do cause
lowercase-string|uppercase-string need to be simplified to string
literal-string&lowercase-string|literal-string&uppercase-string need to be literal-string (same for other accessory)
literal-string&lowercase-string|uppercase-string should stay untouched (i think).

Depends on how hard it is to handle, and how important it is to solve ; it might be postponed in another PR.

Except my previous comment, I don't think I see anything to add on this PR ; good job

[ondrejmirtes]

I reviewed the whole PR again and I like it a lot! Thank you very much.

If you wanted more challenges in the type system now that you proficient in it, there's no shortage of them I can throw at you :)

[staabm]

great job!

[VincentLanglet]

I reviewed the whole PR again and I like it a lot! Thank you very much.

If you wanted more challenges in the type system now that you proficient in it, there's no shortage of them I can throw at you :)

I had a comment left about IntegerType::toString which is both lowercase and uppercase.

I made the PR #3651

[pmjones]

Thanks all, glad it turned out well!

[thg2k]

Do you think it would be doable to introduce something like html-string and sql-string? Wouldn't be too different from uppercase/lowercase-string. Idea being: mysqli_real_escape_string(string): sql-string, and htmlspecialchars(string): html-string, then concat would preserve the semantics (does it?) and stuff like that... The idea being that then mysqli_query(sql-string) and all output(html-string).. just gathering some preliminary input, i'd open a separate issue to discuss that.

[ondrejmirtes]

@thg2k I plan to do "nominal string type". Which means you'll be able to do whatever-string without any special meaning to PHPStan. But whatever-string will only accept another whatever-string. And it will be user's job to write their @phpstan-assert PHPDocs to narrow the types.

[ondrejmirtes]

The implementation would look very similar to this PR.