Skip to content

InvalidKeyInArray: report float deprecation since PHP 8.1 #3220

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

Open
wants to merge 6 commits into
base: 1.11.x
Choose a base branch
from

Conversation

janedbal
Copy link
Contributor

No description provided.

@phpstan-bot
Copy link
Collaborator

You've opened the pull request against the latest branch 1.12.x. If your code is relevant on 1.11.x and you want it to be released sooner, please rebase your pull request and change its target to 1.11.x.

@janedbal janedbal changed the base branch from 1.12.x to 1.11.x July 10, 2024 12:05
@janedbal janedbal marked this pull request as ready for review July 10, 2024 14:03
@phpstan-bot
Copy link
Collaborator

This pull request has been marked as ready for review.

@janedbal
Copy link
Contributor Author

Seeing the integration test failures, this is often triggered when numeric operation is performed with mixed. E.g. $array[$mixed - 1] as $mixed - 1 is float|int.

@staabm
Copy link
Contributor

staabm commented Jul 10, 2024

would it help if $mixed - 1 would get a benevolent (int|float)? I think we did something similar recently

@janedbal
Copy link
Contributor Author

Saying often is maybe too abmitious, I checked few :)


It would be great if integration tests used editorUrlTitle so that you can easily click-to the GitHub source.

@staabm
Copy link
Contributor

staabm commented Jul 10, 2024

the error at https://github.com/pmmp/PocketMine-MP/blob/8dedbb747108c45b7534b8ac6f05e8464ee8eb22/src/crash/CrashDump.php#L229-L234 looks like it might be useful handle IntegerRangeType or getFiniteTypes to get arround the false positive


but maybe its just #3220 (comment)


alternatively you could consider not reporting the "maybe" error for floats because of the too high false-positive rate.

lets see what ondrey thinks about it

];
}

if ($this->phpVersion->getVersionId() >= 80100) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of condition like this, we need a new method on PhpVersion that would be used here.

if ($isFloat->yes()) {
return [
RuleErrorBuilder::message(
'Float used as array key, this emits deprecation notice.',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Message format to be used: Deprecated in PHP 8.1: Float can no longer be used as array key, %s given.

return [
RuleErrorBuilder::message(
'Float used as array key, this emits deprecation notice.',
)->identifier('array.invalidOffset')->build(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

array.floatKey might be better?

if ($this->phpVersion->getVersionId() >= 80100) {
$isFloat = $dimensionType->isFloat();

if ($isFloat->yes()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to use RuleLevelHelper::findTypeToCheck here, it's going to help us on level 9 and also with benevolent union types.

Case in point: $mixed - 1 is already benevolent union type so this problem would already be solved: https://phpstan.org/r/5af2741f-b958-42f7-9248-435416d1b584

@@ -47,6 +51,24 @@ public function processNode(Node $node, Scope $scope): array
];
}

if ($this->phpVersion->getVersionId() >= 80100) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the same points as in the other place :)

@ondrejmirtes
Copy link
Member

We should also have a test for this in LevelsIntegrationTest. The best way to develop that is to comment out all the existing "topics", and add a new one. Write a few code samples in there and run the test. It will (re)generate the current levels-snapshot JSON.

The behaviour I'd like this to have:

  • float always reported since the level where the rule is first registered
  • Partially valid type like float|int or float|string or even float|null to be reported on level 7
  • Everything still reported on level 8
  • mixed reported on level 9 (but mixed~float should not be reported at all)

The thing about float|null on level 7 vs. level 8 is a bit non-standard, because usually it's the other way around. To be honest I'm not sure how to write the $unionTypeCriteriaCallback callback here, that's why we need the tests :)

@janedbal
Copy link
Contributor Author

Altough I agree with your points, I'm not sure I'll invest the time into all that.

Mostly because the core issue is covered in our (even stricter) rule: shipmonk-rnd/phpstan-rules#254

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

Successfully merging this pull request may close these issues.

4 participants