Incorrect Identification of SObjectField type.

[Justin Julicher]

I think screenshot explains it all? Let me know if you need more info.

[Scott Wells]

Do you happen to have a variable named account in the same context? If so, that's the issue, and it's an IC bug, but not a very easy one to fix. Because of the Apex's case-insensitive nature, IC currently resolves Account in that expression to the variable account, and that makes Account.LastActivityDate a field value rather than a compile-time constant for the field LastActivityDate on the SObject type Account. The Salesforce Apex compiler has some special provisions for handling that which I haven't yet implemented.

If there's no variable named account, I'm currently unable to reproduce what you're seeing. Perhaps you could provide a standalone reproducible example?

[Justin Julicher]

No there’s no variable named account.

Here’s the whole top of the class.

The only thing I could think of is the `new Account` declarations below it. But as you can see the very first line in the first method is exhibiting the issue.

[Justin Julicher]

I’ll create a new scratch org and see if I can replicate.

[Justin Julicher]

Ok figured out what it was.

Under the .sfdx dir there were 2 directories: .sfdx/tools/standardObjects & .sfdx/tools/customObjects. Somehow IC was indexing this? So I deleted these dirs and all the issues went away.

I take it those directories are part of the vscode stuff (had a look to see where it was at and it’s crap compared to IC ).

[Scott Wells]

Duplicate of #1356.

[Scott Wells]

Okay, then this is a duplicate of #1356. The workaround is to set .sfdx to be an excluded directory for the project.