Make templating Psalm-specific #8769

greg0ire · 2021-06-15T11:36:23Z

If $className is a class-string, then we return an instance of that
class. However, if it's an alias, things get complicated, and it's hard
to tell. There does not seem to be a way to express that for now.

We should probably consider dropping namespace aliases entirely and add
support for ::class inside DQL if it's not the case already.

Refs #8767 , phpstan/phpstan#5175 , cc @VincentLanglet

VincentLanglet · 2021-06-15T12:00:59Z

Not sure it's the right decision since it works fine for psalm. https://psalm.dev/r/738daf594d
IMHO it should be a feature request for phpstan phpstan/phpstan#5175 (comment)

The only other way to solve this is to drop the string support and only allowing class-string.
As a first step, just removing the string part will solve the issue (and could be the beginning of non passing a class string).

greg0ire · 2021-06-15T17:42:36Z

Maybe yeah. This means the solution would be to use a non-templated version for phpstan with phpstan- annotations, and keep the psalm- annotations as they are I suppose.

greg0ire · 2021-06-15T17:58:41Z

I pushed a commit that does that, but that means we now have a different behavior for Psalm and for Phpstan, and it's going to be hard to satisfy both of them now. To illustrate this, I have added a test within the static analysis directory you introduced.

VincentLanglet · 2021-06-15T22:12:38Z

lib/Doctrine/ORM/EntityManagerInterface.php

@@ -321,11 +321,13 @@ public function hasFilters();
     * {@inheritDoc}
     *
     * @psalm-param string|class-string<T> $className
+     * @phpstan-param string|class-string<T> $className


Suggested change

* @phpstan-param string|class-string<T> $className

* @phpstan-param string $className

VincentLanglet · 2021-06-15T22:20:17Z

I pushed a commit that does that, but that means we now have a different behavior for Psalm and for Phpstan, and it's going to be hard to satisfy both of them now. To illustrate this, I have added a test within the static analysis directory you introduced.

Yes, it reflects more the reality of the different behavior of those libraries, but I clearly don't like it.
It would be nice to have the annotation string|class-string<T> understood by phpstan.

If the feature-request is accepted by phpstan, maybe this code should be untouched.
As soon as the feature will be added to phpstan it string|class-string<T> will be understood instead of string.

Phpstan requires that the template can be resolved in all cases, while Psalm seems to tolerate this ambiguous situation. See phpstan/phpstan#5175 (comment)

greg0ire · 2021-07-04T15:41:11Z

We should probably consider dropping namespace aliases entirely

Related: #6935

VincentLanglet · 2021-07-04T16:04:48Z

We should probably consider dropping namespace aliases entirely

Related: #6935

Deprecation should be introduced to the 2.x branch then ?
And maybe the phpdoc could be updated to drop the string part in order to promote the changes by user.

greg0ire · 2021-07-04T17:16:49Z

Yes, we just created #8818 in case you want to contribute it.
Regarding the phpdoc, I don't think the user is the only thing to take into account: Psalm and Phpstan are going to make this an error when it should just be a deprecation.

VincentLanglet · 2021-07-04T17:37:54Z

Regarding the phpdoc, I don't think the user is the only thing to take into account: Psalm and Phpstan are going to make this an error when it should just be a deprecation.

That's what I had in mind.
The Psalm and PHPstan error will help the developper to update the code where string could have been passed.
To me, this is really similar to deprecation ; when you're using phpunit at the stricter level, deprecation is making the build to fail.

If someone is using phpunit at a strict level, he'll have to add group legacy or fix the code now.
If someone is using phpstan/psalm at a strict enough level, he'll have to ignore the error or fix the code now.

And one of the benefit is that this will fix the following issue phpstan/phpstan#5175 for all the 2.x user, without having to wait for the 3.0 for this.

greg0ire · 2021-07-04T18:43:59Z

I think you might be right, we'll have to see how it looks in practice, IMO it might result in a lot of ignore rules to add for us, as some checks are going to appear redundant, like checking if the string contains a colon.

VincentLanglet · 2021-07-30T15:35:01Z

Should we close this in favor of #8818 @greg0ire ?

greg0ire · 2021-08-01T21:56:14Z

I don't know… #8818 is about deprecating namespace aliases, but it does not remove them, so the issue will remain until 3.0 😬

VincentLanglet · 2021-08-01T22:08:56Z

I don't know… #8818 is about deprecating namespace aliases, but it does not remove them, so the issue will remain until 3.0 😬

I see three "solutions" then.

Merging a PR like yours, phpstan and psalm will have a different behavior.
Doing nothing, I think it will end with the same behavior than the first solution, since phpstan is already transforming string|class-string<T> to string ; but it might be more confusing for developpers.
Changing string|class-string<T> to class-string<T>. This will fix the phpstan issue, but you'll end up with new psalm issues in the doctrine code (see Fix annotation for phpstan #8869) because you're sometimes passing string to the method. This can be quickly fixed by adding them to the baseline. Static analysis error will also encourage developer to stop passing string and pass class-string instead, so it'll help the deprecation. But this might have some sens to do this in the same time than adding the deprecation.

Since the deprecation is planned #8818 / #8820, I would say the option 3 seems the more natural and phpdoc can be pre-emptively fixed in 2.10 version.

greg0ire · 2021-08-02T06:57:54Z

Thanks for laying out the 3 options again @VincentLanglet ! As you know, I'm not too fond of the 3rd option, since it will express that namespace aliases are no longer supported (and break some pipelines), when they will in fact still be supported. Not everybody treat deprecations as a failure in their CI.

@orklah hi! Do you have a recommendation on this one?

orklah · 2021-08-02T11:20:13Z

I agree that since namespace aliases are still supported, we shouldn't remove string from phpdoc (Psalm will probably complain too if there's code for handling non-class-string where the phpdoc says it can't happen)

I also understand the behavior in PHPStan and I wouldn't see that as a bug in the tool. string|class-string is indeed a string the same way that false|bool is a bool.
Unfortunately, once this has been said, we're left with a complicated situation because psalm and phpstan will both try to read annotations that were made for the other tool (for compatibility) and that force us to have both @psalm-param and @phpstan-param in order to satisfy everyone.

However, Doctrine is widely used and we're fortunate to have plugins custom made for it to handle the quirks that can't be handled natively with annotations.

So my advice would be to use @psalm annotations to describe the ideal behavior, use @phpstan annotations that doesn't use templates, ignore the issues that may arise in phpstan and ping the maintainers of the phpstan doctrine plugin that a special handling is needed here. When namespace aliases will be removed, this will be easy to go back to a single annotation for both tools and the case will be removed in the plugin

greg0ire · 2021-08-02T16:26:21Z

Sounds good to me! Does that sound OK to you @VincentLanglet ?

VincentLanglet · 2021-08-02T17:59:59Z

Sounds good to me! Does that sound OK to you @VincentLanglet ?

Sure

SenseException

There was so much thought put into this, that I'm not sure if I missed something important. 😅
But it will become easier once the aliases are gone.

greg0ire force-pushed the remove-unhelpful-template branch from a43d469 to 7da82bc Compare June 15, 2021 11:44

greg0ire marked this pull request as ready for review June 15, 2021 11:46

greg0ire added the Bug label Jun 15, 2021

greg0ire force-pushed the remove-unhelpful-template branch 2 times, most recently from 9b7d61d to b5b1a70 Compare June 15, 2021 17:58

greg0ire force-pushed the remove-unhelpful-template branch from b5b1a70 to 2674be4 Compare June 15, 2021 18:03

VincentLanglet reviewed Jun 15, 2021

View reviewed changes

Limit template annotations to Psalm

8bb564d

Phpstan requires that the template can be resolved in all cases, while Psalm seems to tolerate this ambiguous situation. See phpstan/phpstan#5175 (comment)

greg0ire force-pushed the remove-unhelpful-template branch from 2674be4 to 8bb564d Compare June 16, 2021 06:14

greg0ire changed the title ~~Remove template from method signature~~ Make templating Psalm-specific Jun 17, 2021

greg0ire requested a review from SenseException August 2, 2021 16:26

SenseException approved these changes Aug 3, 2021

View reviewed changes

greg0ire merged commit 055b646 into doctrine:2.9.x Aug 4, 2021

greg0ire deleted the remove-unhelpful-template branch August 4, 2021 05:42

greg0ire added this to the 2.9.4 milestone Aug 4, 2021

github-actions bot mentioned this pull request Aug 11, 2021

Merge release 2.9.4 into 2.10.x #8913

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make templating Psalm-specific #8769

Make templating Psalm-specific #8769

greg0ire commented Jun 15, 2021 •

edited

Loading

VincentLanglet commented Jun 15, 2021

greg0ire commented Jun 15, 2021

greg0ire commented Jun 15, 2021

VincentLanglet Jun 15, 2021

VincentLanglet commented Jun 15, 2021 •

edited

Loading

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 4, 2021

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 4, 2021

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 30, 2021

greg0ire commented Aug 1, 2021

VincentLanglet commented Aug 1, 2021

greg0ire commented Aug 2, 2021

orklah commented Aug 2, 2021

greg0ire commented Aug 2, 2021

VincentLanglet commented Aug 2, 2021

SenseException left a comment •

edited

Loading

	* @phpstan-param string\|class-string<T> $className
	* @phpstan-param string $className

Make templating Psalm-specific #8769

Make templating Psalm-specific #8769

Conversation

greg0ire commented Jun 15, 2021 • edited Loading

VincentLanglet commented Jun 15, 2021

greg0ire commented Jun 15, 2021

greg0ire commented Jun 15, 2021

VincentLanglet Jun 15, 2021

Choose a reason for hiding this comment

VincentLanglet commented Jun 15, 2021 • edited Loading

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 4, 2021

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 4, 2021

greg0ire commented Jul 4, 2021

VincentLanglet commented Jul 30, 2021

greg0ire commented Aug 1, 2021

VincentLanglet commented Aug 1, 2021

greg0ire commented Aug 2, 2021

orklah commented Aug 2, 2021

greg0ire commented Aug 2, 2021

VincentLanglet commented Aug 2, 2021

SenseException left a comment • edited Loading

Choose a reason for hiding this comment

greg0ire commented Jun 15, 2021 •

edited

Loading

VincentLanglet commented Jun 15, 2021 •

edited

Loading

SenseException left a comment •

edited

Loading