Class scoping problem when define $this using @var

[yeganemehr]

Bug report

PHPStan reports a false positive error in this scenario:

1. Include another file in a class method.
2. In that file, define $this explicitly using PHPDoc
3. Access to a private/protected class member, Code running correctly but PHPStan detect an error.

This technique widely seen in scripts and template systems in order to make classes (mainly view classes) members accessible to their templates (HTML part).

Code snippet that reproduces the problem

I have this repo that make you check this bug faster:

git clone https://github.com/yeganemehr/phpstan-class-scoping-issue.git

but for sake of make everything documented, I put code snippets here:

file1.php

<?php
class A
{
    protected string $test1 = "successful";

    public function run(): void
    {
        require __DIR__ . "/file2.php";
    }

    private function test2(): string
    {
        return "successful";
    }
}

$obj = new A();
$obj->run();

file2.php

<?php

/**
 * @var A $this
 */
echo $this->test1 . PHP_EOL;
echo $this->test2() . PHP_EOL;

Reported Error:

 ------ -------------------------------------------- 
  Line   file2.php                                   
 ------ -------------------------------------------- 
  6      Access to protected property A::$test1.     
  7      Call to private method test2() of class A.  
 ------ --------------------------------------------

Expected output

It's a legit code and it's work in PHP with no error, so it's expecting from PHPStan to report no error about it.

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

PHPStan is now an essential tool for me and my colleagues.
Your work enable us to write better and more reliable codes.
Thank you ❤️

[mergeable]

This bug report is missing a link to reproduction at phpstan.org/try.

It will most likely be closed after manual review.

[yeganemehr]

Oh dear bot 😄 in try zone I can't reproduce require.

[ondrejmirtes]

Thank you for your kind words! :)

Tthis isn't how object-oriented code is typically written. I'd suggest you to stop using require for this purpose and write your code directly in the class.

[Hackwar]

We, the Joomla project, have the same issue. For legacy reasons, our templates/layouts are PHP files which are included in a class scope and this is now throwing lots of false positives. Is there any way to maybe write an extension which pulls the current code into the scope of $this when that is explicitely declared?

[Hackwar]

We still have this issue. Would there be any chance for a hint how we could create a plugin to circumvent this? I looked at the repo, but right now I wouldn't know where to even start...

[staabm]

@Hackwar please create a reproduction for your problem, either on phpstan.org/try or even a small reproducing repository in case it does not work on phpstan.org/try

[yeganemehr]

@staabm I did it 2 years ago. See the first post.
https://github.com/yeganemehr/phpstan-class-scoping-issue

[Hackwar]

For now I excluded these errors, but it would be really good if this could be solved. Basically, define the current code to be as part of the context of $this.

[justinbeaty]

@yeganemehr @Hackwar I believe I have solved this problem for a Magento 1.9 fork that has the same issue. The solution was hinted way back in this comment: #351 (comment)

See these files:
https://github.com/justinbeaty/maho-phpstan-plugin/blob/main/src/PhpDoc/BindThisScopeResolverExtension.php
https://github.com/justinbeaty/maho-phpstan-plugin/blob/main/src/Reflection/PublicMethodReflection.php
https://github.com/justinbeaty/maho-phpstan-plugin/blob/main/src/Reflection/PublicPropertyReflection.php

And in exension.neon:

    -
        class: Maho\PHPStanPlugin\PhpDoc\BindThisScopeResolverExtension
        tags:
            - phpstan.parser.richParserNodeVisitor
            - phpstan.phpDoc.typeNodeResolverExtension

Basically it looks for PHPDoc comments like /** @var SomeClass $this */, then returns a custom ObjectType with all methods and properties turned public. I think it should also resolve #10936.

---

@ondrejmirtes Could the WrappedExtendedMethodReflection and WrappedExtendedPropertyReflection constructors be covered under the API? Here's an excerpt from the above code:

return new class($className) extends ObjectType {
    public function getMethod(string $methodName, ClassMemberAccessAnswerer $scope): ExtendedMethodReflection
    {
        return new WrappedExtendedMethodReflection(
            new PublicMethodReflection(parent::getMethod($methodName, $scope))
        );
    }
    public function getProperty(string $propertyName, ClassMemberAccessAnswerer $scope): ExtendedPropertyReflection
    {
        return new WrappedExtendedPropertyReflection(
            new PublicPropertyReflection(parent::getProperty($propertyName, $scope))
        );
    }
};

 ------ ------------------------------------------------------------------------------------------------------------------------- 
  Line   PhpDoc/BindThisScopeResolverExtension.php
 ------ ------------------------------------------------------------------------------------------------------------------------- 
  77     Creating new PHPStan\Reflection\WrappedExtendedMethodReflection is not covered by backward compatibility promise. The
         class might change in a minor PHPStan version.
         🪪  phpstanApi.constructor
         💡 If you think it should be covered by backward compatibility promise, open a discussion:
         💡 https://github.com/phpstan/phpstan/discussions
         💡
         💡 See also:
         💡 https://phpstan.org/developing-extensions/backward-compatibility-promise

  83     Creating new PHPStan\Reflection\WrappedExtendedPropertyReflection is not covered by backward compatibility promise. The  
         class might change in a minor PHPStan version.
         🪪  phpstanApi.constructor
         💡 If you think it should be covered by backward compatibility promise, open a discussion:
         💡 https://github.com/phpstan/phpstan/discussions
         💡
         💡 See also:
         💡 https://phpstan.org/developing-extensions/backward-compatibility-promise

 ------ ------------------------------------------------------------------------------------------------------------------------- 

[Hackwar]

@justinbeaty Thank you for working on this. I'm looking into this and at this moment it feels like it doesn't work for traits in the modified class. I have some strange behavior, which I'm trying to debug... I'll keep you updated.

[ondrejmirtes]

I'm not willing to extend the public API to support this hack. This should be implemented inside PHPStan. I can imagine a couple of new PHPDoc tags that you'd put at the top of the file would be able to support this use-case:

/**
 * @phpstan-this-type Foo
 * @phpstan-this-scope Foo
 */

These two PHPDoc tags at the top of the .php file would support typing $this properly and also tell PHPStan about the scope, so it does not complain about accesing private methods and properties.