PHPStorm showing nonsensical PHP version error in stub code Follow
Um... what?
I accidentally Cmd+clicked on an `fopen` call in code, and it opened standard_5.php, with things underlined in red, like that `default` thing (nevermind all of the silly HTML inside of the block comments, I don't know why that's there), giving an error about PHP 8 compatibility, but my Language Level for the repo project right now is PHP 5.6 (SORRY! I can't update it right now, I just have to work with it until we can update it).
Can someone explain this? I'm not sure what to think of this. PHPStorm is directing me to reference code that it says is broken... so... like... show me proper reference code?
Please sign in to leave a comment.
You're missing the point that PHPStorm is suggesting a function that can't be used in the current selected language level the way the editor is telling me it's a non-existent format. Why do you think that's not a problem? I explained in my OP why it was.
Why am I getting sent to a doc stub that isn't valid for the selected language level? That makes NO sense. I need the stub for the selected language level, not a future version that if used in the project will break the app.
If the selected language level for the project is PHP 5.6, the stubs we get sent to need to be for that language level. Not the latest PHP version or something too far ahead.
If the selected language level for the project is PHP 7.4, the stubs we get sent to need to be for that language level.
If the selected language level for the project is PHP 8.1, the stubs we get sent to need to be for that language level.
Why is that not logical to do? Why is that not being done in this case?
> Since the stubs are not supposed to be read by the user, there's no reason you should be concerned about the language level used in the stubs.
If they're not supposed to be read by the user, then why does Cmd+click on a PHP function go to the stubs declaration? Have you never done that in PHPStorm?
This is a common thing to do in PHPStorm, or any editor, for any function, built-in (to the language) or not. I and millions of other developers have been doing it with the dozens of code editors in existence over the years; it's nothing new.
Cmd+click a function in an app you're coding in, sometimes it's not apparent whether it's a PHP function or a custom one made by some developer defined in another repo file.
Cmd+clicking a PHP function has always gone to the stub in PHPStorm:
Why are you talking like we shouldn't be doing this basic function tracing thing we've been doing for years and years and years? Did JetBrains just accidentally implement this feature, and we're not supposed to use it? That would mean that we're already supposed to know all PHP functions so that we never accidentally go to the stub.
Do you understand what I'm saying here? This is a huge usability problem.
Not only are we shown suggestions (without even having to go to the stub) in the drop-down (while we're typing or manually-activated) that are for future versions of PHP than the language level we're using in the project, but the editor's default function trace behavior opens the stub, sometimes for the wrong version.
Are you understanding the problems here?
Why would a sensible editor show suggestions or go to stub declarations of unusable code versions of the function or its declaration?
This is making ZERO SENSE.
This is a bug in the completion feature, not in the stubs.
It just has to be fixed: https://youtrack.jetbrains.com/issue/WI-62475
In this thread, our QA engineer briefly explains why the stubs look this way. This is not going to be changed any time soon.
This shouldn't happen though. Can you share a sample of code where it's the case?
> an error about PHP 8 compatibility
It clearly states "arguments are allowed since PHP 8.0". While you're working on a PHP 5.6 project, I don't see any contradictions here.
Anyway, these are stub files that IDE uses to provide code completion for built-in PHP objects. You're not required to fix that code or to follow the inspections guidance there.
Because when we decided on how to introduce stubs versioning, the attributes was the way we chose to go.
Since the stubs are not supposed to be read by the user, there's no reason you should be concerned about the language level used in the stubs.
Not sure I understand this. Please elaborate how exactly you intend to use stubs that it will break something in your project.