Player->showPlayer() assumes that spawnTo() will take care of all the checks necessary to ensure we don't actually spawn a player to someone it shouldn't be able to see. In PM3, there's nothing we can do about that.
This could be a problem if anything decides to override spawnTo() to do additional stuff and assumes that the function will always succeed; however, there's not much reason to do that (plugins sending packets should override sendSpawnPacket() instead).
this should never be hit in the PM case, but it's an InvalidArgument rather than AssumptionFailedError because plugins can and do call this with bad things.
setGenerated/setPopulated and friends set hasChanged = true, which causes the world to autosave them the first time around, even though they weren't modified.
PHPStan failed on 7.4 after updating to 0.12.99, and I figured it was less hassle to just do this than fix the build. In any case, we stopped shipping 7.4 months ago, and warned at 3.22 release that 7.4 support would soon be dropped.
this was originally worked around by 47f7af6739537af7a4d356a08aa00eb7feefd1ed. However, that commit was just duct tape, and I never bothered to investigate if the config was being checked somewhere else.
Here's to a years-old bug finally getting fixed.
while annoying, PHPStan is right to complain about this, because putBool() is impure, meaning that these fields could have been mutated in the call.
We know they didn't, but PHPStan doesn't, and we can't mark the method as pure because .. well .. it isn't.
while it's true that you might be able to skip the CPU waste from verifying a player's login just to find out that they are banned, this is generally a minority case anyway, so it doesn't make a lot of difference overall. This additional note is essentially a recommendation premature optimisation, which will likely lead to people making security mistakes.
