Add a config option to ignore self-deprecations

[VincentLanglet]

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

?

[ondrejmirtes]

This should already work because accessing something deprecated from deprecated scope isn't reported.

[VincentLanglet]

This should already work because accessing something deprecated from deprecated scope isn't reported.

My bad, I made a mistake in my example.

Indeed when the method is deprecated there is no issues.
But when the method is not deprecated but do things like

     public getFoo():
     {
          if ($this->foo) {
              trigger_deprecation(...);
              return $this->foo;
          }

          return $this->newFoo;
     }

and will be changed to

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

in next major, we have the phpstan error. (And we have a lot of code like this in the library)

[VincentLanglet]

I started to think that maybe the notion of "self-deprecation" wasn't something easy for PHPStan.
In this case ignoring deprecation per namespace could be easier with a config like:

ignoreNamespace:
    - 'App\NamespaceToIgnore'
    - 'AnotherNamespace`

But I think it could be ignored by something like

ignoreErrors:
        -
            message: '#deprecated .* App\\NamespaceToIgnore#'
            path: .

Does this feature would worth an option or do you think the regex-solution is enough ?
Also if you're in favor of the regex @ondrejmirtes,

• Do you think an universal regex could/should be added to the doc ?
• Should we write tests about this regex to be sure all the errors messages respect this regex ?