Types from base class are shown as red

[Attila Hajdrik]

I found an interesting issue working with https://github.com/jamessimone/apex-rollup it has a Rollup class which is a base class for a lot others like RollupFullBatchRecalculator and in this class' source I see InvocationPoint and CalcItemBag as red, because these are defined deep in the class inheritance.

It affects code completion, etc

‌

[Scott Wells]

Let’s try the easy thing first. If you completely rebuild indices does the problem go away? If not, can you reproduce this via a skeletal project? I have some projects with VERY deep inheritance hierarchies and numerous inner types and have only seen something like when the indices are in a bad state, but if you have a reproduceable example, definitely provide it so I can reproduce it as well.

[Scott Wells]

I’m being dumb. Let me try the linked project real quick.

[Attila Hajdrik]

Oh whenever I see red I fully regenerated the symbol table…trust me, did not help. If I referenced the type as Rollup.CalcItemBag it was colored correctly…

[Scott Wells]

Okay, reproduced. I’ll take a look. It’ll probably be beginning of next week, but my guess is that it’s something simple. I’ll keep you posted.

[Scott Wells]

Committed a fix for the main issue. There are still a couple of issues flagged in that project incorrectly, specifically where Id-type fields evidently work just fine with methods from the String type. First I’ve seen of that and still trying to decide how (or even whether) I want to deal with that given how niche it seems to be. But the main issue should be fixed in this week’s build.

[Scott Wells]

Okay, so actually those remaining issues (ignoring the ones from missing installed managed packages like dlrs) were legitimate. I also fixed the following three in the context of this bug report:

1. Instances of interfaces were not being treated as instances of Object, so references to toString() were not being resolved properly.
2. MDT external lookup fields were being rendered into the OST as type Id when they are actually type String.
3. An upsert external ID field of the form TypeName.FieldName wasn’t resolving properly.

With these four fixes (the three above plus the original one), this project looks quite good, except for, as stated above, the missing external dependencies. I’m going to get those into the org so I can see this project go through a full-project inspection run without any errors.

UPDATE: I’ve now installed Nebula Logger and dlrs and the only reported Apex issue is legitimate for a final field that’s initialized in a loop and could therefore be initialized more than once.

[Scott Wells]

Delivered in 2.2.4.7.

[Attila Hajdrik]

Awesome, thanks!