@mixin function return type lost

JakubMisek

Thank you for reporting the issue;

It looks ok for me:

It may be a bug in tooltips; can you try @trace annotation (if you have inlay hints enabled) (as shown in the picture above):

/** @trace $a */

roben

This is what it looks like for me. I also added an auto completion preview where the property xyz is not detected. Strangely though, while I was typing the @trace annotation, it showed A but it changed shortly after back to mixed.

I also checked that I have no other PHP extensions running besides the DEVSENSE ones.

roben

Oh strange, I just did the same thing in a new Code Window outside our project and there it works. So it seems to be an issue related to our project or its configuration.

roben

So I have a rather large .php file, where I dump stuff like this and quickly run things during development and leave older code for reuse behind an exit. This is also where I created my initial example. After discarding the remaining code in this file it started working again. Then I did a binary search to find the culprit. And it seems to be a rather unrelated line of code:

And here it gets funky:

(I renamed A to Aclass while trying to find the issue)

So it seems to pick up $shop which is declared only later in this file (but only if it is used) and that breaks $a.

JakubMisek

roben thank you for playing around with it.

I guess renaming the variable $a to something else doesn't fix it?

How does it know, what the $shop is? :-)

roben

I guess renaming the variable $a to something else doesn't fix it?

Nope, renamed it to $somethingSpecial but the issue remains.

How does it know, what the $shop is? :-)

That really is curious. It's not even declared anymore in this file but the type still remains. I will dig further and report back if I find something.

JakubMisek

roben It's a global variable, so it can be assigned anywhere as a global variable. The editor is watching for all the uses.

Plus - if a function (i.e. get_api) has an annotation like @global Application_Model $shop:

/**
 * @global Application_Model $shop
 */
 function get_api() ...

The editor will resolve $shop wherever get_api() is called :)

roben

It should not be global, but it is possible. I'll have to dig into the code for this. But I don't understand how this would change the type of $a (or whatever other name I give it).

JakubMisek

roben me neither ... I'll try to repro the issue locally.

JakubMisek

OK I think I have figured this out ...

It seems this is the limitation of our editor. The type inferring engine can track up to 62 various types within a routine (global scope of a file, function, method, lambda). Once there's more than that, any new type just falls back to mixed.

So if you have a large file with variables that have lots of distinct types, it may end up "dumb".

roben

Thanks for digging into this. Is it possible to increase this number? The initial problem for which I have created the basic example is in fact in a rather large file. The same issue does not come up in a much smaller file (which I did not notice earlier).

JakubMisek

roben This is currently our limitation based on 64-bit arithmetic.

We'll be upgrading it in the future, but not planned for now.