Code completion is showing duplicate values.

[James Loughney]

I am currently using IntelliJ IDEA 2022.3.2 (Ultimate Edition) (Build #IU-223.8617.56, built on January 25, 2023)

Along with Illuminated Cloud 2 version 2.2.5.6

‌

I have noticed more recently that when using the Code completion I am seeing duplicate entries for some of the suggested method names.

The referenced type in this screenshot example is an interface and it is implemented in 2 separate classes. There are no overloads for these methods. Do you have any idea why they would be shown like this?

‌

[Scott Wells]

Hi. Thank for reporting. Are you able to reproduce this in a small, standalone project that could be attached/shared so that I can see where the duplicates are being sourced?

[James Loughney]

A small project to show examples of duplicate method names being displayed.

[James Loughney]

Hi Scott. Please find a sample project included. I hoe this shows what you need. I am not particularly familiar with sfdx project structures so apologies if this is missing some config. However, the code should show an example of the duplication that I am seeing.

‌

After my initial post I did realize something that might be causing the issue, although I am not really sure if this is expected or not.

I believe the duplicate method names are appearing in the list because I have a class called Person, and the method parameter name is ‘person’. I think the code completion is picking up the method names based on that class as well as the methods declared in the interface. As I said, I am not sure if this is expected behavior so thought it best to mention it to you.

If you need anything else, please let me know.

Many thanks,

James

‌

[Scott Wells]

Thanks, James. Yes, that helped me to reproduce it. It’s not due to the inheritance relationship, though. If you rename the constructor arg person to p you won’t see this issue.

Because of Apex’s case-insensitive nature, person here is seen as both the variable of type IPerson and the type Person. When IC2 adds variant completions (though after . or ?., it tries the determine the type of the identifier for which variants are being requested. In this case it saw both IPerson and Person as candidate types, and because one is an instance and the other isn’t, it adds both instance and class variants. Again, if you changed the arg name from person to p (or anything other than the type name), p. would show only the instance variants from IPerson:

‌

and Person. would show only the class variants from Person:

‌

The remaining real issue is that it’s showing instance variants from the type Person when that was specifically added as a type and not the type of an instance, but making it treat each found type based on how it was found instead of changing to an “unsure” mode and showing both is a very complex change.

So I think this is working as designed at present. Hopefully the explanation I’ve provided above will help provide sufficient context.

[Scott Wells]

Okay, so this one haunted me after I resolved it. Technically what I said is correct, and the overall behavior is relatively benign...but it's also not as accurate as it could be. Today I played around with it a bit and managed to retain sufficient context about the class vs. instance state of each of the potential types being completed such that the exact subset of completions is offered in this situation. I obviously need to test to make sure I didn't bork anything as a result, but assuming it holds up under further scrutiny I'll plan to include it in the next (non-Spring '23) build.

[James Loughney]

Hey Scott,

I certainly didn’t mean for you to lose sleep over this or anything :) I just wanted to make you aware of the problem.

Thanks for looking into the problem. I love Illuminated Cloud and use it every day. So I really appreciate all the work you do.

Thanks,

James

[Scott Wells]

Oh, it’s not a problem! For starters, the second I resolved the issue as wontfix I regretted it. That’s the only resolution that reflected my stance (effectively “works as designed”), but I hate the term as it seems dismissive (at best). That got it rattling around in my head, though, and that ultimately led to a hunch on a (hopefully) low-risk way to resolve the remaining issue. I feel a much better sense of closure now, so well worth the time.

Glad to hear you enjoy the product!

[Scott Wells]

Delivered in 2.2.5.7.