Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow @phpstan-use (and @use) in PHPdoc-block for classes #7486

Open
nagmat84 opened this issue Jun 17, 2022 · 11 comments
Open

Allow @phpstan-use (and @use) in PHPdoc-block for classes #7486

nagmat84 opened this issue Jun 17, 2022 · 11 comments

Comments

@nagmat84
Copy link

Feature request

PHPStan only recognizes annotations, if the annotation is inside a PHPdoc block (see PHPStan: PHPDocs Basics). But PHPdoc blocks are only allowed for structural elements of the PHP language as well as files, include and require statements (see phpDocumentor: What can be documented in your source code?).

However, if one uses a generic trait with a template parameter, one has to annotate the use-statement with the proper template parameter like this

/**
 * @template TDataType
 */
trait MyTrait {}

class MyClassA {}

class MyClassB {
  /** @phpstan-use MyTrait<MyClassA> */
  use MyTrait;
}

This is not 100% ideal as there are other tools (e.g. CS Fixer for PHP) which convert those wrongly placed PHPdoc comments into normal comments.

A solution would be to put this annotation into the PHPdoc block of the class (similar to @extends) like this

/**
 * @template TDataType
 */
trait MyTrait {}

class MyClassA {}

/**
 * @phpstan-use MyTrait<MyClassA>
 */
class MyClass {
  use MyTrait;
}

Did PHPStan help you today?

Currently, we are enabling PHPStan for Lychee as part of this PR LycheeOrg/Lychee#1336. While we are struggling with a lot of false positives due to the used framework, it already helped us to discover a lot of bugs which were dormant in less frequently used features of Lychee.

@ondrejmirtes ondrejmirtes added this to the Generics milestone Jun 17, 2022
@ondrejmirtes
Copy link
Member

This is fairly easy to do. Places that read ResolvedPhpDocBlock::getUsesTags() need some modification. And instead of modifying UsedTraitsRule, I'd welcome an extra new rule.

@nagmat84
Copy link
Author

Your comment sounds a little like you would like me to implement it. But I do not feel qualified at all. I can write a simple additional inspection rule using your guide, but as soon as it involves interaction with different components of PHPStan, I am lost.

@ondrejmirtes
Copy link
Member

Do not feel obligated - it's a hint for everyone that feels like doing this :)

@nagmat84
Copy link
Author

Why have you closed this issue?

@ondrejmirtes ondrejmirtes reopened this Jun 17, 2022
@ondrejmirtes
Copy link
Member

Sorry, that was by mistake.

@javaDeveloperKid
Copy link

Why have you closed this issue?

Ondrey likes to close issues faster that the speed of light.

@joelharkes
Copy link

any progress on this, i was trying to doctype my trait wondering why it wouldnt work as i thought it would be in the class block

@kiler129
Copy link
Contributor

kiler129 commented Dec 29, 2022

This will also break with generics inheritance: https://phpstan.org/r/953e9ea0-604f-4ce7-b64f-b3a9352b9845

The message reported will be Class FooClass uses generic trait FooTrait but does not specify its types: TTrait (added here mostly for googlers)

@baptistepillot
Copy link
Contributor

I had the same wish today, so I implemented it.
It is available in this version : https://github.com/baptistepillot/phpstan-src/tree/1.10.x
What I've changed into phpstan source code : baptistepillot/phpstan-src@ac779f0
The pull request for 1.10.x : phpstan/phpstan-src#2638

@mxr576
Copy link
Contributor

mxr576 commented May 2, 2024

I have also bumped into this problem in Drupal, where DrupalCS (via PHPCS) does not allow docblock comments above trait use statement.

{
    "message": "Inline doc block comments are not allowed; use \"\/* Comment *\/\" or \"\/\/ Comment\" instead",
    "source": "Drupal.Commenting.InlineComment.DocBlock",
    "severity": 5,
    "fixable": false,
    "type": "ERROR",
    "line": 53,
    "column": 3
}

@mxr576
Copy link
Contributor

mxr576 commented May 2, 2024

@ondrejmirtes It seems to me that #2638 implements a different approach than what you have described in #7486 (comment). Would you also accept the solution in #2638 or rather a new PR should be raised that would implemented your suggested approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants