Hello everyone 👋

I announced today that PHPStan 1.0 is going to be released on November 1st 2021.

I'm approaching you as one of the most popular PHPStan extensions. I'd love if you could prepare your code for PHPStan 1.0 in advance so that it's ready to release on the same day.

Here's a brief guide how to approach the upgrade:

1. Create a branch 🌴
2. Update your composer.json to "phpstan/phpstan": "^1.0", add "minimum-stability": "dev" and "prefer-stable": true if necessary.
3. Update your code with the BC breaks below in mind. 🔧
4. Fix the code so that it passes PHPStan's analysis 🤓
5. Wait for PHPStan 1.0 release on November 1st, merge your branch and tag the next major version 👍

Thank you!

Here are the BC breaks. The list is huge but most of those have very little impact.

There are new rules around using PHPStan internals in regard to backward compatibility promise: https://phpstan.org/developing-extensions/backward-compatibility-promise

It's possible that not everything you use is covered by it - so I'm here to help you to transition to correct usage, or add some @api annotations in PHPStan itself so that more is covered by the promise. Let me know!

BC breaks for end-users

• Level max is now level 9. Feel free to update max to 8 if your code isn't ready.
• Description of some types was updated to match the syntax in PHPDocs. This includes numeric-string (it was previously described as string&numeric), and also array shapes.
• Removed baselineNeon error formatter, use --generate-baseline CLI option instead (phpstan/phpstan-src@492cfbc)
• Removed polluteCatchScopeWithTryAssignments config parameter (phpstan/phpstan-src@8933c7e)
• Removed deprecated autoload_files parameter - use Discovering Symbols instead (phpstan/phpstan-src@7a21246)
• Removed deprecated autoload_directories parameter - use Discovering Symbols instead (phpstan/phpstan-src@f67b48a)
• Removed bootstrap parameter - use bootstrapFiles instead (phpstan/phpstan-src@1baa294)
• Moved implicitThrows configuration parameter to exceptions.implicitThrows (phpstan/phpstan-src@96b7c48)
• Removed --paths-file CLI option (phpstan/phpstan-src@5670cf2)
• Removed dump-deps command (phpstan/phpstan-src@9c7017c)
• Deprecated excludes_analyse option, use excludePaths instead (phpstan/phpstan-src@d25c5e5)

The following are interesting only if you create a custom ruleset in your configuration file:

• Removed DeadCatchRule, replaced by CatchWithUnthrownExceptionRule (phpstan/phpstan-src@4dba60b)
• Removed VariableCertaintyInIssetRule, replaced by IssetRule (phpstan/phpstan-src@2e858de)
• Removed MissingClosureNativeReturnTypehintRule, no longer needed thanks to type inference (phpstan/phpstan-src@1c34d8d)
• Rename rules with typos (phpstan/phpstan-src@003ab1a)

BC breaks for extension developers

• Extensions are checked with rules for correct usage of PHPStan internals according to backward compatibility promise.
• Removed CompoundTypeHelper (phpstan/phpstan-src@145c4e3)
• Removed CommentHelper (phpstan/phpstan-src@ebad6f6)
• Removed DependencyDumper (phpstan/phpstan-src@9c7017c)
• Removed PHPStan\Reflection\Generic\ResolvedFunctionVariant, replaced by PHPStan\Reflection\ResolvedFunctionVariant (phpstan/phpstan-src@1cc6c81)
• Removed ClassReflection::getNativeMethods(), use getNativeReflection() instead (phpstan/phpstan-src@d2c1446)
• Removed PhpPropertyReflection::hasPhpDoc(), replaced by hasPhpDocType() (phpstan/phpstan-src@bedd5be)
• NodeDependencies no longer iterable (phpstan/phpstan-src@f76875a)
• Renamed TestCase to PHPStanTestCase (#634), thanks @frankdejonge!
• StaticType and ThisType - require ClassReflection in constructor (phpstan/phpstan-src@7aabc84)
• PHPStanTestCase - extensions can no longer be provided by overriding methods from PHPStanTestCase. Use getAdditionalConfigFiles() instead. (phpstan/phpstan-src@65efd93, phpstan/phpstan-src@239291a)
• Removed some unused internal helper methods from Broker (phpstan/phpstan-src@d578151)
• Changed return types of various methods that had |false to |null (phpstan/phpstan-src@629ccf6)
• Type generalization precision is now a required argument (phpstan/phpstan-src@6568103)
• Some constructor parameters are now required (phpstan/phpstan-src@1f4062f)
• Deprecated BrokerAwareExtension (phpstan/phpstan-src@db2f7fb)
• Deprecated PHPStanTestCase::createBroker(). Use createReflectionProvider() instead. (phpstan/phpstan-src@1e5cf58)
• Deprecated PHPStan\Broker\Broker. Use PHPStan\Reflection\ReflectionProvider instead. (phpstan/phpstan-src@c775594)
• Deprecated PHPStan\Broker\Broker::getInstance(). Use PHPStan\Reflection\ReflectionProviderStaticAccessor instead. (phpstan/phpstan-src@4e7d60d)

Hi,

Sorry if this is very basic question. I only recently started using phpstan and I came across this rule. I don't understand what is the proper way to do this? Why is a constructor parameter with default value bad?

I tried to research this, but I could not find anything..

Excerpt from my code that triggers this rule:

final class Client
{

public function __construct(
    protected string $endpoint,
    protected string $access_key,
    protected string $secret_key,
    protected int $timeout = 10,
    protected null|int $retryTimes = null,
    protected null|int $retryMilliseconds = null,
) {
}

First of all thank you for sharing your phpstan rules!

There are some rules (the nullable-rules to be precise) where I get the intention, but I am not sure how to avoid violations in some cases. I think there might also be a lack of understandment why some rules might be a good idea.

I think the rules would benefit from a brief description on why they should be applied and how to avoid violations.

abstract Doctrine entities should not require final methods.

final methods will not work here because proxies will want to override them.

/cc @OskarStark

I'm greeted with composer version restriction errors when installing on PHP 8.0 RC1, saying this package requires PHP 7.

Are you waiting for PHP 8.0 to become stable (i.e. leave beta) before providing an upgrade for this package or are you open to making this work with pre-stable versions of 8.0 as well?

See

• https://twitter.com/spazef0rze/status/1669369211280412675
• https://github.com/phpstan/phpstan-src/blob/1c8894d4538e5a18b91ddf1475c1793b98ec1e05/src/Rules/RuleErrorBuilder.php#L129

Related to #77.

This package is recommended to be used on top of phpstan/phpstan-strict-rules which already has a DisallowedEmptyRule. As such I think the NoEmptyRule should be removed from this package.

I can send a pull request if you agree.

Steps required to reproduce the problem

1. go to https://github.com/ergebnis/phpstan-rules/releases/tag/0.15.3
2. play detective to find actual changes
   

It's night impossible due to 95% dependabot noise.

Expected Result

Only show relevant project changes (I identified two comments making sense) or separate them in a more readable way. I figure a release summary should be for humans and not machines.

Thanks 😄

Steps required to reproduce the problem

1. Create a class as follows:

class MyTestCase extends \PHPUnit\Framework\TestCase
{
    // ...
}

2. Add the following configuration to phpstan.neon:

services:
    -
        class: Localheinz\PHPStan\Rules\Classes\FinalRule
        arguments:
            allowAbstractClasses: true
            classesNotRequiredToBeAbstractOrFinal:
                - \PHPUnit\Framework\TestCase
        tags:
            - phpstan.rules.rule

Expected Result

• FinalRule does not complain about MyTestCase not being final or abstract

Actual Result

• Class MyTestCase is neither abstract nor final. is reported when running PHPStan.

Would it be sane to support parent classes and infer if a class inherits from them to allow skipping the final check? Or would a whole new option argument (e.g. ancestorClassesNotRequiredToBeAbstractOrFinal)?

Kinda defeats the purpose of this rule, but sometimes devs might have dependences that embrace the inheritance, and adding loads of exceptions into the config is not that feasible, and is error prone when it comes to teaching new devs about what that all is about and when to use it.

abstract Doctrine entities should not require final methods.

final methods will not work here because proxies will want to override them.

/cc @OskarStark

When using Symfony's new way to set up a bundle https://symfony.com/doc/current/bundles/extension.html#loading-services-directly-in-your-bundle-class, the following error is emitted by NoParameterWithContainerTypeDeclarationRule:

Method FooBundle\FooBundle::loadExtension() has a parameter $builder with a type declaration of Symfony\Component\DependencyInjection\ContainerBuilder, but containers should not be injected.

I'm suggesting to make an exception for this case, i.e. don't show an error if the method name is xxxBundle::loadExtension()

Reference: https://twitter.com/localheinz/status/1174221387571109890

https://phpstan.org/r/3c374bde-8916-47c7-9442-58ccc2929047

declare(strict_types = 1);

final class HelloWorld
{
	/** @var int */
	private $foo = 1;
	
	public function getFoo(): int
	{
		return $this->addFoo($this->foo, 1);
	}
	
	private function addFoo(int $a, int $b): int
	{
		return $a + $b;
	}
}

Expected

+---------------------------------------------------------------------------------+
| Line | test.php                                                                 |
+---------------------------------------------------------------------------------+
| 13   | Method addFoo is not declared static but doesn't use any $this reference |
+---------------------------------------------------------------------------------+

 [ERROR] Found 1 error 

Actual

 [OK] No errors 

A private method that does not access any instance members of the containing class can be easily marked as static.

This has the following advantages:

• a developer can immediately see that the method does not access any instance membes
• a static method can be used in static closures, which means that by turning a non-static method into a static method, perhaps non-static closures can be marked as static

Also see #90.

Please, add support for phpstan versions 0.13 and 0.14

The Attributes equivalent of the @ORM\Entity annotation should be whitelisted too in FinalRule.php

Would be nice to be able to disable all rules and then enable them one by one like this: https://github.com/phpstan/phpstan-strict-rules#enabling-rules-one-by-one

Hi, following FinalRule for classes I would propose FinalMethodRule for public methods of abstract classes, see https://slamdunk.github.io/blog/when-to-declare-methods-final/

I have a phpstan-extension package too but yours is more focused on strictness, so such a rule would fit better here.

Would you consider a PR for this topic?

We just switch to doctrine/coding-standard 10.x, which enforces explicit types, like ?string=> string|null.
After the switch (and the code fix) ergebnis/phpstan-rules doesn't recognize these anymore, it says Ignored error pattern #Function ... has a nullable return type declaration# was not matched in reported errors.
Since it is still nullable, the error should still be thrown.

I'd like to use some of the rules from this package. However some other rules are a bit too much. Is it possible to configure this to only use some of the rules but not all of them?

For instance I want to avoid the declare strict rule because that's already taken care of by my very strict coding standard and it's entirely unnecessary to make the already slow phpstan pipeline even slower by double checking it. And while I do agree with most of the rules, a few of them (especially those regarding nullable types) might be a bit too aggressive.

Note that I'm using phpstan/extension-installer so it isn't an option to avoid including your configuration and only copy some parts of it manually.

I'm using most of the rules from https://github.com/shipmonk-rnd/phpstan-rules for instance but it very easily allows me to disable some of them. Something like that would be ideal.

The Methods\PrivateInFinalClassRule reports a false negative for a protected method in a final class when that method overrides a method provided by an extended class.

https://twitter.com/IssecMura/status/1231178838589218816.

/cc vladyslavstartsev

I would like to use the FinalRule and I've tried to write my own implementation before I stumbled over your package. Do you have any solution for the problem that doctrine entities must not be final because of their proxy classes? I understand that I can whitelist them one by one in your implementation, but that does not feel too clean as I have to adjust the config file of a CI tool every time I add something in my domain layer. I also don't put them into one huge Entity directory, so the location is no indication neither. Do you have any suggestions?

Type: feature

Add rules disable functionality.
From config perpective it could look something like this:

ergebnis:
              NoExtendsRule:
                       enable: false

              // then other options to rules could look like this
              FinalRule:
                       allowAbstractClasses: false
                       classesNotRequiredToBeAbstractOrFinal:
			       - Foo\Bar\NeitherAbstractNorFinal

This way there is rule options indepencdence

Steps required to reproduce the problem

Define a trait with a protected method and a final class using this trait.

Expected Result

No error, methods defined in a trait should be ignored by this rule.

Actual Result

PrivateInFinalClassRule will report this method as that it should be private, however this is only true in the context of that class and may not be true for other usages of the trait.

Related PHP-CS-Fixer rule: static_lambda

Lambdas should always be static to ensure no one can rebind them and so no one can alter their behavior.

Starting with version 0.12 an check failed on an interface.

Steps required to reproduce the problem

<?php
/**
 * This file is part of the ios-build package.
 *
 * Copyright (c) 2019, Thomas Mueller <[email protected]>
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

declare(strict_types = 1);
namespace IosBuild;

interface IosBuildInterface
{
    /**
     * Takes iOS build code and returns corresponding iOS version.
     *
     * @param string $needle the build code
     *
     * @throws BuildException
     * @throws NotFoundException
     *
     * @return string JSON encoded string
     */
    public function getVersion(string $needle): string;
}

2. run PHPStan including this library against this file.

Expected Result

 [OK] No errors

Actual Result

 ------ -------------------------------------------------------------------------------------------------------------------------
  Line   IosBuildInterface.php
 ------ -------------------------------------------------------------------------------------------------------------------------
  26     Method IosBuild\IosBuildInterface::getVersion() is not final, but since the containing class is abstract, it should be.
 ------ -------------------------------------------------------------------------------------------------------------------------


 [ERROR] Found 1 error