Cannot Resolve Symbol for Inner Classes when Outer Class name matches name of Custom Object (minus "__c")
Issue first noticed May 9, 2019. First use of Illuminated Cloud on Mac OS.
To Reproduce:
- Create a Custom Object named
MyObject__c
. - Create a project with an Illuminated Cloud modules whose metadata subscription includes
MyObject__c
. - Create an Apex class named
MyObject
. - Create an inner class,
MyObject.MyInnerClass
. - Create another Apex class
MyReferencingClass
. - 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.
Comments (6)
-
repo owner -
reporter 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 calledMyCustomObject
containing a file namedChangeEvent
.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
-
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
-
A file called
MyOuterClass__c.cls
Workspace using
Expense
object asMyOuterClass
(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.
-
-
reporter @Scott Wells :
Looked into this more. I am still fairly sure that there are two ways objects like
MyObject__ChangeHistory
andMyObject__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 theMyObject.cls
file, providing aMyObject.ChangeEvent
symbol but hiding theMyObject.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
andCustomObjectName__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 asMyObject__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.
- file:
-
reporter Current workaround is to edit the symbol table manually, replacing particularly troublesome instances of
MyObject/ChangeEvent.cls
(and similarly-named cases) withMyObject__ChangeEvent.cls
. That seems to work, at least until the symbol table is regenerated. -
repo owner - changed status to resolved
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.
-
reporter Acknowledged.
Haven’t noticed any issues with this error lately. If I do, I’ll reopen this ticket. Thanks for your help!
- Log in to comment
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
, andExpense__c
resolve successfully. Is there perhaps some other nuance to this that I overlooked?