Skip to content
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

fix return type of sprintf with single %s format #3167

Merged
merged 2 commits into from
Jun 19, 2024

Conversation

pilif
Copy link
Contributor

@pilif pilif commented Jun 19, 2024

In the return type extension of sprintf(), there was a shortcut to assume the return type to be non-falsy-string when the format-string is non-falsy string.

That's not correct though if the format string is just a single '%s' placeholder (or a single '%x$s' placeholder). In that case, if the requested argument is of stringy-type, then the return type is the type of the stringy argument.

This commit extends the existing support for single-placeholder templates that currently deals with numeric placeholders to also deal with %s

this fixes phpstan/phpstan#11201

@pilif
Copy link
Contributor Author

pilif commented Jun 19, 2024

please note the second commit in the PR that updates an existing test (930266c)

That test case was invalid to begin with as the line in question would throw an ArgumentCountError at runtime.

The other option would be to remove the test-case entirely. I can totally do both.

@pilif
Copy link
Contributor Author

pilif commented Jun 19, 2024

(heads up: I'm about to force-push a much better test that has many more assertions)

In the return type extension of sprintf(), there was a shortcut to
assume the return type to be non-falsy-string when the format-string is
non-falsy string.

That's not correct though if the format string is just a single '%s'
placeholder (or a single '%x$s' placeholder). In that case, if the
requested argument is of stringy-type, then the return type is the type
of the stringy argument.

This commit extends the existing support for single-placeholder
templates that currently deals with numeric placeholders to also deal
with %s

this fixes #11201
the format string is referencing an invalid argument (argument 10)
(which will cause an error at runtime) and then asserts the return type
to be `numeric-string`.

Now that the previous commit has an improved check for invalid argument
number specifiers, the numeric-string shortcut won't work any more.

I'm updating this test because the test-case will throw at runtime
anyways, so both return-types are pointless anyways.
@staabm
Copy link
Contributor

staabm commented Jun 19, 2024

I am also working on this extension for a few hours with some kind of general overhaul. it will also fix your issue.

we should sync how we want to proceed :)

@pilif
Copy link
Contributor Author

pilif commented Jun 19, 2024

up to you. My PR is, by virtue of me being totally unfamiliar with the code base, the minimal change required to fix the problem.

Feel free to close this one in preference to your overhaul, or merge this one as a stop-gap (the underlying bug has cased real-life issues for me) and rebase your overhaul on top of this one - I'm totally fine with both.

@staabm
Copy link
Contributor

staabm commented Jun 19, 2024

just opened a draft of my current state. would it be ok for you, that we concentrate on my PR first (because it moves a lot of moving parts, and we put your one later on top of it?).

#3168

@pilif
Copy link
Contributor Author

pilif commented Jun 19, 2024

absolutely. that's good for me too.

I'll have a look whether your PR fixes the underlying bug and if so, all that's needed from me is my test-case (66262bb#diff-4d390d0bba719512f2479a712fd2d14e7131ad079d4dd8fcced037744e3f1df8)

@ondrejmirtes ondrejmirtes merged commit f513931 into phpstan:1.11.x Jun 19, 2024
451 of 453 checks passed
@ondrejmirtes
Copy link
Member

Thank you!

If you have any improvements, you can send a follow-up PR 😊

@pilif
Copy link
Contributor Author

pilif commented Jun 19, 2024

haha - it looks like @ondrejmirtes just caused some additional work for @staabm

Thank you for deciding for us - that saves me personally quite a bit of work

#3168 doesn't fix phpstan/phpstan#11201 on its own I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants