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

checkExplicitMixed - hardcoded functions in NodeScopeResolver like array_map and array_filter expect wrong callable #5609

Closed
ondrejmirtes opened this issue Sep 9, 2021 · 7 comments
Labels

Comments

@ondrejmirtes
Copy link
Member

Bug report

Code like this:

	/**
	 * @return Entity[]
	 */
	public function getSavableEntities() : array{
		return array_filter($this->entities, function(Entity $entity) : bool{ return $entity->canSaveWithChunk() and !$entity->isClosed(); });
	}

fails with:

 ------ ----------------------------------------------------------------------------------------------
  Line   src/pocketmine/level/format/Chunk.php
 ------ ----------------------------------------------------------------------------------------------
  644    Parameter #2 $callback of function array_filter expects (callable(mixed, mixed): bool)|null,
         Closure(pocketmine\entity\Entity): bool given.
 ------ ----------------------------------------------------------------------------------------------

Because the reflection layer is unaware of the "genericness".

Code snippet that reproduces the problem

checkExplicitMixed not yet supported on phpstan.org

Expected output

No errors

@mergeable
Copy link

mergeable bot commented Sep 9, 2021

This bug report is missing a link to reproduction on phpstan.org.

It will most likely be closed after manual review.

@ondrejmirtes
Copy link
Member Author

Fixed: phpstan/phpstan-src@ca7deb3

@dktapps
Copy link
Contributor

dktapps commented Sep 13, 2021

I'm still seeing the same bogus errors on PM with 0.12.99, e.g. https://github.com/pmmp/PocketMine-MP/pull/4457/checks?check_run_id=3585690922#step:10:9

@ondrejmirtes
Copy link
Member Author

@dktapps It's fixed if you enable bleedingEdge.

@dktapps
Copy link
Contributor

dktapps commented Sep 13, 2021

Is the fix that disruptive? Ouch ...

@ondrejmirtes
Copy link
Member Author

The fix accidentally implements this which can be considered a new rule (many new errors reported in existing codebases): #1954

@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants