When we deprecate a function or method, we also document the replacement to use. For example,

/**
 * @deprecated Use bar instead
 */
function foo() {}

Currently when foo is used in the code, this rule only says foo is deprecated.

Call to deprecated function foo()

It would be very useful if it shows the deprecation text Use bar instead in the message as well.

Call to deprecated function foo(). Use bar instead.

This may be because it is an internal type, but in the jetbrains stubs it looks like this:

class ReflectionType
{
	/* Methods */
	/**
	 * Checks if null is allowed
	 * @link https://php.net/manual/en/reflectiontype.allowsnull.php
	 * @return bool TRUE if NULL is allowed, otherwise FALSE
	 * @since 7.0
	 */
	public function allowsNull()
	{
	}

	/**
	 * Checks if it is a built-in type
	 * @link https://php.net/manual/en/reflectiontype.isbuiltin.php
	 * @return bool TRUE if it's a built-in type, otherwise FALSE
	 * @since 7.0
	 */
	public function isBuiltin()
	{
	}

	/**
	 * To string
	 * @link https://php.net/manual/en/reflectiontype.tostring.php
	 * @return string Returns the type of the parameter.
	 * @since 7.0
	 * @deprecated 7.1 Please use getName()
	 * @see \ReflectionType::getName()
	 */
	public function __toString()
	{
	}

    private final function __clone() {}

}

• Add deprecations errors for functions typehints ‒ InFunctionNode
• Also make errors prettier for anonymous class in deprecations for class method typehints

Hi @eiriksm, after your latest changes in phpstan-src, there are now failures in this repo:

1) PHPStan\Rules\Deprecations\CallToDeprecatedMethodRuleTest::testDeprecatedMethodCall
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
 '07: Call to deprecated method deprecatedFoo() of class CheckDeprecatedMethodCall\Foo.
+10: Call to deprecated method deprecatedFoo() of class CheckDeprecatedMethodCall\Bar.
 11: Call to deprecated method deprecatedFoo2() of class CheckDeprecatedMethodCall\Foo.
 14: Call to deprecated method deprecatedFooFromTrait() of class CheckDeprecatedMethodCall\Foo.
 15: Call to deprecated method deprecatedWithDescription() of class CheckDeprecatedMethodCall\Foo:
 Call a different method instead.
 '

phar:///home/runner/work/phpstan/phpstan/extension/vendor/phpstan/phpstan/phpstan.phar/src/Testing/RuleTestCase.php:84
/home/runner/work/phpstan/phpstan/extension/tests/Rules/Deprecations/CallToDeprecatedMethodRuleTest.php:23

2) PHPStan\Rules\Deprecations\CallToDeprecatedStaticMethodRuleTest::testDeprecatedStaticMethodCall
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
 '06: Call to deprecated method deprecatedFoo() of class CheckDeprecatedStaticMethodCall\Foo.
+08: Call to deprecated method deprecatedFoo() of class CheckDeprecatedStaticMethodCall\Bar.
 09: Call to deprecated method deprecatedFoo2() of class CheckDeprecatedStaticMethodCall\Foo.
 11: Call to method foo() of deprecated class CheckDeprecatedStaticMethodCall\Foo.
 12: Call to method deprecatedFoo() of deprecated class CheckDeprecatedStaticMethodCall\Foo.
@@ @@
 Do not touch this at all.
 16: Call to deprecated method deprecatedWithDescription() of class CheckDeprecatedStaticMethodCall\Foo:
 This is probably a singleton.
-24: Call to deprecated method deprecatedFoo() of class CheckDeprecatedStaticMethodCall\Foo.
 '

Can you please look into it so we know what needs fixing? If the tests asserts here are reasonable then phpstan-src needs fixing, or these asserts need to be edited.

The same problem is with deprecated constant defined in interface and used via subclass.

See e.g. https://github.com/nette/application/blob/v2.4/src/Application/IRouter.php#L22 used with SimpleRouter:

Code \Nette\Application\Routers\SimpleRouter::SECURED throws no error

this rules - as is - support phasing out deprecated functinality which was marked as @deprecated beforehand (which implies that I rather own the code and can mark it deprecated, or I agree with the deprecations of a external person and follow their judgment).

it would be great if phpstan-deprecation-rules could support more advanced use-cases like phasing out a dependency/package.

lets say we want to soft-migrate a existing codebase with a legacy http client to a more modern http client. that means we want to make sure, new code which gets implemented should use the new client. existing code-sites should be reported by phpstan as usage of deprecated functionality.

both - the new and the old http client - are 3rd party libraries and therefore we don't have control over annotating the sources.

I guess this could work with some kind of composer-package-name based deprecation rules, or mabye php namespace based ones.

This PR

• [x] uses ergebnis/composer-normalize instead of localheinz/composer-normalize

Related to https://github.com/ergebnis/composer-normalize/issues/266.

💁‍♂ For reference, see https://localheinz.com/blog/2019/12/10/from-localheinz-to-ergebnis/.

looks like currently deprecated constructor argument types are not detected by phpstan's deprecation rules.

not entirely sure whether this could be tested at all as it would require quite some juggling and assumptions on non-typehinted arguments?

so this is more or less a question of whether or not you want this to be part of the ruleset and whether you have any ideas on how to tackle these instances.

willing to put in some time to if necesary...

I think using a deprecated class/method/property/whatever (let's name those as entity) shouldn't be reported as an error but as a warning. The key differences I see here are:

• The code using a deprecated entity will run, it just might break one day, but PHPStan will then trigger an error about the entity being unknown.
• Reporting a warning instead of an error should not make the CLI exit with a status code different than 0, but it should still output the deprecation message.

Sometimes I deprecate some classes/methods in my code until I'm sure I don't use them anymore, however PHPStan will then complain about them, so I must ignore the errors, which defeats the purpose of using those deprecation rules.

What do you think about this?

The merge method on Doctrine\ORM\EntityManager is marked as deprecated directly on the code (link).

But no error/waring is being prompted by the extension.

If I create the stub below with the annotation than it works as expected.

<?php

namespace Doctrine\ORM;

class EntityManager
{
    /** @deprecated */
    public function merge(object $entity): void;
}

This extension will only read deprecations that I add on my code or in stubs? Or is this a bug on the extension?

It is not that clear on the README which is the right behavior

Hi,

I really like this option to test for usage of deprecated functions. I have quite some tests that runs the deprecated code and would prefer to keep it like that till the deprecated code is removed.

Is it possible to exclude the deprecation rules for some files/folders, without excluding it completely from PHPStan check?

Feature request: When overriding a class property in a child class, that is marked as deprecated in the parent class, a warning should be given. Currently only accessing such properties within methods of the child class triggers this warning.

This would be particularly useful for cases where an upstream package marks a property as deprecated, and where the intended method of setting the property is through overriding it with a new (default) value within the child class, without explicitly accessing it in any method on the child class.

A real world example of such a case is the planned removal of the dates property in Laravel, which won't be detected as a deprecated property currently when overriding it. A code example that currently does not yield any warning:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Foo extends Model
{
    protected $dates = ['foo'];
}

phpstorm-stubs use JetBrains\PhpStorm\Deprecated annotation to mark method's, class e.t.c This annotation allows for more detailed description of the problem and suggested changes.

Other projects use this annotation as well

Can deprecation-rules show it in the same way like @deprecated ?

When exposing a library, you need to respect semantic versioning and avoid BC-break.

Let's say you have some code

class Foo
{
     /** @deprecated */
     protected $foo;

     private $newFoo;

     public getFoo():
     {
          return $this->foo ?? $this->newFoo;
     }
}

An error is reported because $this->foo; is used but changing this/removing it would be a BC break.

But the phpstan-deprecation-rules would still be useful to detect when I use a deprecated method from another library.

Is it possible to add an option in order to

• Turn off errors if the deprecated Method/Interface/Property/Class/... is from my project
• Keep the erros if the deprecated Method/Interface/Property/Class/... is coming from a vendor

?

Bug report

I am using phpstan in combination with phpstan-deprecation-rules and getting false-positives in my test classes since a deprecation annotation has been added to PHPUnit.

The code detecting deprecations in phpstan-deprecation-rules looks good:

$classReflection = $this->reflectionProvider->getClass($referencedClass);
$methodReflection = $classReflection->getMethod($methodName, $scope);

if (!$methodReflection->isDeprecated()->yes()) {
    continue;
}

But the $methodReflection is pointing to the method defined in the (TestCase) base class instead of the overwriting method in the ProphecyTrait.

To reproduce this issue easily, I have created a minimal setup.

source file to check

<?php

declare(strict_types=1);

trait MyTrait
{
    protected function prophesize(): void
    {
        echo 'Trait';
    }
}

abstract class MyBaseClass
{
    /** @deprecated Use MyTrait::prophesize() */
    protected function prophesize(): void
    {
        echo 'Base';
    }
}

final class MyClass extends MyBaseClass
{
    use MyTrait;

    public function callProphesize(): void
    {
        $this->prophesize(); // wrongly detected deprecation
    }
}

phpstan.neon

parameters:
    level: max
    paths:
        - src

includes:
    - %rootDir%/../../phpstan/phpstan-deprecation-rules/rules.neon

Expected output

I am expectiong that the $methodReflection variable is pointing to MyTrait::prophesize() so that $methodReflection->isDeprecated()->yes() returns false and no deprecation is detected by phpstan-deprecation-rules.

Did PHPStan help you today? Did it make you happy in any way?

phpstan is a great tool that helps a lot in daily work.

for https://github.com/doctrine/dbal/blob/3.5.1/src/Platforms/AbstractPlatform.php#L225 this lib currently emit:

Call to deprecated method getVarcharTypeDeclarationSQL() of class AnonymousClass6a85eed1b3aeaa3b7eaea1eb536990ed:
Use {@link getStringTypeDeclarationSQL()} instead.

from AnonymousClass6a85eed1b3aeaa3b7eaea1eb536990ed it is very hard to tell which class and also I double the name is stable for error ignore.

I would expect anonymous name like from native phpstan https://phpstan.org/r/7f7ac916-f7fe-4c4d-8035-337e837344ae, ie. class@anonymous/tmp.php:7 istead of AnonymousClass6a85eed1b3aeaa3b7eaea1eb536990ed.

Hi, I have problem with depracation rules in GitLab CI. I have following code

<?php declare(strict_types = 1);

namespace App\Core\Controls\Base\Grid;

use Nette\ComponentModel\IContainer;
use Nette\Localization\Translator;

class GridFactory
{

	protected Translator $translator;

	public function __construct(Translator $translator)
	{
		$this->translator = $translator;
	}

	public function create(?IContainer $parent = null, ?string $name = null): Grid
	{
		$grid = new Grid($parent, $name);
		$grid->setTranslator($this->translator); // problematic line

<?php declare(strict_types = 1);

namespace App\Core\Controls\Base\Grid;

use Ublaboo\DataGrid\DataGrid;

class Grid extends DataGrid
{
}

DataGrid is external library, in setTranslator, it accepts depracated ITranslator. So i added it to ignore. On local is everthing ok, but in GitLab CI, i am getting following error.

 Ignored error pattern #^Parameter \#1 \$translator of method           
         Ublaboo\\DataGrid\\DataGrid\:\:setTranslator\(\) expects               
         Nette\\Localization\\ITranslator, Nette\\Localization\\Translator      
         given\.$#

On local and CI i have same PHP version. Any suggestioins???