Cannot Resolve Symbol for Inner Classes when Outer Class name matches name of Custom Object (minus "__c")

[quietopus]

Issue first noticed May 9, 2019. First use of Illuminated Cloud on Mac OS.

To Reproduce:

1. Create a Custom Object named MyObject__c.
2. Create a project with an Illuminated Cloud modules whose metadata subscription includes MyObject__c.
3. Create an Apex class named MyObject.
4. Create an inner class, MyObject.MyInnerClass.
5. Create another Apex class MyReferencingClass.
6. Deploy Apex classes, Retrieve Metadata, Generate Symbol Table, Invalidate Caches and Restart, etc.

References to MyObject.MyInnerClass from inside of MyReferencingClass generate a "Cannot resolve Symbol" error.

[Scott Wells]

I just tried to reproduce this unsuccessfully. Here's a screenshot of what I've done using an existing Expense__c custom object:

All references to Expense.MyInnerClass, Expense, and Expense__c resolve successfully. Is there perhaps some other nuance to this that I overlooked?

[quietopus]

There appear to be different ways of representing MyObject__ChangeEvent in the off-line symbol table, depending on some nuance I have not been able to determine in the time I have to investigate this.

In the non-error-triggering case, the offline symbol table (the zip file containing the generated code) contained a file named MyCustomObject__ChangeEvent. In the error-triggering case, there is a directory called MyCustomObject containing a file named ChangeEvent.

Investigation

It just so happened that my org also had an object called Expense, a remnant of a sample package I installed long ago. I tried again with that object and the error did not appear.

Supposing the outer class / custom object is called MyOuterClass, I found the following symbol table structure after refreshing various symbol tables and inspecting them:

Workspace originally causing the error

• A directory called MyOuterClass

  • A file called ChangeEvent.cls
  • A file called History.cls

• A file called MyOuterClass.cls

• A file called MyOuterClass__c.cls

Workspace originally created when filing this ticket (also causes error)

• A directory called MyOuterClass

  • A file called ChangeEvent.cls

• A file called MyOuterClass__c.cls

Workspace using Expense object as MyOuterClass (no error)

• A file called MyOuterClass__c.cls
• A file called MyOuterClass__ChangeEvent.cls

Cannot investigate this more right now, but let me know if you need any more information. If there is something I can let you know easily, I’ll send it along.

[quietopus]

@Scott Wells :

Looked into this more. I am still fairly sure that there are two ways objects like MyObject__ChangeHistory and MyObject__ChangeEvent are represented in the offline symbol table:

• file: MyObject__ChangeEvent.cls
• file-in-directory: MyObject/ChangeEvent.cls

I am also fairly sure that the file-in-directory method causes the error. Presumably, the MyObject directory is prioritized over the MyObject.cls file, providing a MyObject.ChangeEvent symbol but hiding the MyObject.MyInnerClass symbol.

However, I am officially stumped as to how Illuminated Cloud decides which representation to use. Perhaps the symbol table generator has difficulty distinguishing between Namespace__NativeObjectName and CustomObjectName__StdSuffix formats (treating the latter as if it is the former)? Just speculating.

Here are some things I've observed:

• In Salesforce, opened the edit page for a test Object using the the file-in-directory approach (the Object I created for the To Reproduce section of this bug report). Disabled all of its Optional Features and Object Classification options (for brevity, let’s call these extra features) and regenerated the symbol table. After this, the symbol table used a file approach instead of a file-in-directory approach. The error went away.
• Opened the edit page for an Object using the file approach (the Expense object mentioned earlier). Enabled all of its extra features (all were initially disabled), added one tracked field, and regenerated the symbol table. Symbol table continued to use the file approach, although extra files (such as MyObject__ChangeHistory.cls) were created.
• Created two new Objects from scratch, one using all extra features and the other one using no extra features. Deleted the symbol table’s zip file and regenerated the symbol table. Both new Objects used the file-in-directory approach.
• Opened the edit page for the Object originally causing the error. This Object was using the file-in-directory approach. Disabled its extra features and regenerated the symbol table. Still using the file-in-directory approach. Sill an unresolved symbol error.

The first bullet point would, for the moment, be an effective temporary workaround. However, the same approach failed in the last bullet point when I applied it to my actual project. Until I learn more, my best guess is that Illuminated Cloud has a psychic awareness of when I need the workaround to be effective and intelligently chooses whichever option causes the most frustration.

[quietopus]

Current workaround is to edit the symbol table manually, replacing particularly troublesome instances of MyObject/ChangeEvent.cls (and similarly-named cases) with MyObject__ChangeEvent.cls. That seems to work, at least until the symbol table is regenerated.

[Scott Wells]

I believe this should be fixed now (as of 2.1.0.1, but perhaps based on earlier changes). Resolving, but if you still see it, please feel free to reopen.

[quietopus]

Acknowledged.

Haven’t noticed any issues with this error lately. If I do, I’ll reopen this ticket. Thanks for your help!