-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Psalm 5.11.0 #5830
Psalm 5.11.0 #5830
Conversation
How am I supposed to read and understand errors like this one?
cc @orklah – sorry for the ping, but I'm really stuck here. I'm getting error messages that don't fit into my 🧠. 🙈 |
@derrabus that's a big error! Here is a more legible version: https://www.diffchecker.com/It5OguUg |
Thanks @greg0ire. Take a look at the failures, there's more where this came from. 🙈 |
For a somewhat better clarity: EDITED @greg0ire gave a better version :) With Psalm 5, array{} is now sealed so if the first form is expected, you should have no extra keys in the second form. There's a few extra keys here, especially inside the So you have different options:
|
Note: While I know it's yet additional work, and OSS time is not free, adding shapes declared as aliases would help a lot here For example, just in the error you posted, there are 13 occurences of the type Having 13 times 451 chars replaced by 13 "ConnexionInfo" would have reduced this error by more than half |
Thanks a lot @orklah ! Lines 32 to 75 in db3ad9c
But maybe there are occurrences that are not replaced yet, we will have to check. |
Thank you for chiming in @orklah. Once I take a look at the formatted error, I think I somewhat know what to do. My problem is rather that Psalm throws a single-line 10 KB error message at me for which I need external tooling.
But doesn't Psalm inline those aliases when rendering the error message? This big shape that we see in the error message is already composed of type aliases and I don't see them in the output at all. |
Yeah, my bad, Psalm does inline everything, this is unfortunate as it would help a lot. I'll create a ticket, even if I'm not sure what can be done now that I think about it. |
3e0d445
to
118f46f
Compare
9e0e8f1
to
aa8b860
Compare
aa8b860
to
0b7fe40
Compare
0b7fe40
to
31922e7
Compare
</MethodSignatureMustProvideReturnType> | ||
<NoValue> | ||
<errorLevel type="suppress"> | ||
<!-- We're checking for invalid input. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like a bug. You shouldn't end up with NoValue while checking types from docblock. Do you know at which line it is emitted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can give you a reproducer: https://psalm.dev/r/614cec5f0f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I think it happens because the type is both from signature and from docblock, I'll check that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error occurs because I first eliminate all possible values (according to the docblock) for a variable and afterwards use its value when rendering the exception message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I know, the thing is that when a type comes from a docblock, when every type is refuted, Psalm assign the mixed type to it. It only applie the never type when the type came from signature. Here you have a signature but you actually have a more detailed type in docblock
149b11a
to
26dd1c9
Compare
I figured whatever I so here will be too heavy for the bugfix branch. Rebased to 3.6.x, so I can start cherry-picking some fixes. |
Apparently, Psalm has become super-picky about the
This happens because Psalm can't possibly know that the given SQL will result in a string result and that's okay. However, it should be okay to use a Also, it's a bit annoying that this kind of error is apparently always reported twice, once for the return type declaration ( |
b7966bf
to
2744b69
Compare
Agree. It's actually a bug: vimeo/psalm#9049
That confused me too, but if you account the fact that Psalm can fix some code, it makes sense you'd not want to treat that kind of error the same way. Fixing LessSpecificReturnStatement would probably involve some kind of casting or check for the return whereas fixing MoreSpecificReturnType would involve broadening the return type in phpdoc or signature. You could suppress one of those globally on the project depending on where you want to get the error if you want |
Oh good. I was about to get mad about that one. Thanks. 😅
Okay, if you put it this way, it makes sense. 👍🏻 |
2744b69
to
7cf2dca
Compare
21083b0
to
dc94fc9
Compare
Nice, Psalm finally reports problematic array keys Probably me, right? 😅 |
Okay, vimeo/psalm#9049 still hurts big time. I can't work with |
e9b0c6c
to
4263e6f
Compare
Thanks for the fix, @orklah. This allowed me to remove some error suppressions. However, the issue with
Again, the error is valid, just not on the level of strictness that we're running on. |
Could you try to replicate on a smaller scale on psalm.dev? |
I'll try. I've reported another issue that pops up several times: vimeo/psalm#9604. |
b605959
to
4ecd445
Compare
This is the issue I'm seeing: https://psalm.dev/r/6c49e6544a Again, the error itself is valid, it's just that I get it not matter what I set the |
Closing in favor of #6061. |
The Psalm upgrade is a massacre. 🙈
This is my current WIP state, in case anyone feels like completing it.