Why does IC inspection flag most of my DML statements as wrong?

[Alan Birchenough]

I feel I must be missing something obvious regarding the inspection called "Illegal Assignment". If I perform a DML operation such as "insert" using any type other than SObject or List<SObject> I get a fatal inspection error saying "Expected [SObject, List<SObject>]; found Product2" or whatever the case may be.

The noise contributed by this inspection is considerable, masking what might be real issues. On the other hand, I don't want to turn it off entirely, so I must live with the noise. Might I suggest a more discerning approach to DML or other situations where use of subtypes of SObject is benign? Alternatively, perhaps the remedy is something I can apply myself - if so, that remedy is not clear to me. (And I'd rather not cast everything to SObject or List<SObject> before operating on it.) Thanks for any advice.

[Scott Wells]

Alan, what you're seeing doesn't sound normal. IC does properly handle expression type comparisons in a polymorphic manner. Otherwise a large number of lines of code in every project would be marked as illegal assignments. Let's try a test...the following should not raise any illegal assignment problems for you:

List<Account> accounts = new List<Account>();
insert accounts;

List<SObject> sobjects = accounts;
insert sobjects;

Does it? If it doesn't, can you provide a simple example of something that does?

[Alan Birchenough]

That makes sense, and I can perform the tests you have requested. As I think about this though, I believe I should make absolutely sure that I have a full and intact OST first. I imagine IC relies on that information for data about polymorphism as it performs these checks.

[Alan Birchenough]

I've got a nice example for you here. The first screenshot shows an insert statement on a list of pse__Project_Task__c records. That statement is being flagged with the error referenced above.

‌

A further bit of evidence comes from a SOQL query on that same object. The second screenshot shows a slice of the SELECT list on that object. Observe that the Id field is flagged as undefined. Clearly something has gone wrong with the inheritance of the Id field from SObject.

‌

‌

I will attach the OST for this org after I finish this post. I could also attach a log, but I wonder if it will be particularly revealing since this appears to be the only gap in this particular OST. (I ran the “Unresolvable Reference” inspection to check.) At any rate, if you need a log it is possible that if I regenerate the OST this same problem will recur. I don’t know; these things aren’t always reproducible. So please let me know if you need any further collateral. Meanwhile, I hope this helps,

–- A.

[Alan Birchenough]

Here is the OST to accompany the two recent screenshots.

[Scott Wells]

Thanks for the details, Alan. I’ll try to take a look today and let you know what I find.

[Scott Wells]

Alan, I just set up a new project against your OST and am not seeing these issues:

It's like IC hasn't properly computed/cached the inheritance relationship. Let's try a few things. First, please make sure you're on the latest release build of the product just in case you're hitting an issue that I've already resolved. If you're already up-to-date, or if updating doesn't resolve the issue, can you try completely rebuild caches/indices to see if that resolves the issue? You can start with the button under Illuminated Cloud>Configure Project. If that doesn't do it, you can use the nuclear option under File>Invalidate Caches / Restart.

Let me know if any of that helps.

[Alan Birchenough]

Yes. Rebuild caches/indices fixed it. I didn’t realize that was in the repertoire of things I could have tried. Thanks for pointing me to it (and the nuclear option too, just in case I need it one day).

[Scott Wells]

It shouldn't get into that state. Whatever is causing that is a bug for me to fix. The problem is that it's pretty rare for it to get into such a bad state so it's difficult to debug directly. I often have to try to infer root cause from downstream behavior. If you find that this is happening with any frequency/consistency, please let me know. I'll also be trying to corner it on my side.