Inspection error reported when returning soql query directly in a method

[John De Santiago]

Given the following code snippets, Line #2 shows inspection error "Cannot Resolve Symbol". It only happens to the Project__c object and my assumption is that it is because there is a managed package that shares the same name minus the namespace. If I return the query to a variable rather than as a return statement the code is not flagged.

        return [SELECT Id FROM Account];
        return [SELECT Id FROM Project__c];
        return [SELECT Id FROM TaskRay__Project__c];
        List<Project__c> results = [SELECT Id FROM Project__c];

This has no affect on saving or running the code it just shows up as an error in the inspection results.

[Scott Wells]

Thanks for reporting, John. I'll let you know if I can't reproduce it, but assuming I can, I'll plan to address it for the next build.

[Scott Wells]

Just to clarify, what is the return type of the containing method? Is it List<Project__c>, List<TaskRay__Project__c>, List<SObject>, or a single item version of one of those?

[John De Santiago]

Containing method is List<Project__c>. I also found that this reports the same error as well:

    public Database.QueryLocator start(Database.BatchableContext context) {
        return Database.getQueryLocator([SELECT Id FROM Project__c]);
    }

[Scott Wells]

Thanks, John. You say that it only happens with Project__c, and only when used without the namespace qualification. Is that right? That matches what I see in the provided screenshot where both Project__c and its Id are highlighted in red meaning they're unresolvable. My guess is that your project is misconfigured slightly with regard to the namespace. When you look at the connection properties for the project's connection, what does it show for Organization namespace? If it doesn't show TaskRay, click the Test button and that should not only verify the credentials, but also fetch the namespace from the org. If that does populate the org namespace properly for the connection, regenerate your OST and I think these issues should go away. If none of that is as as-speculated, or if that doesn't help resolve the issue, let me know.

[John De Santiago]

I should have clarified. Project__c exists twice in the system. Once has a custom object under the default namespace and secondly as TaskRay__Project__c.

This is a client org that has a custom object called Project__c but also has the TaskRay managed package installed which has it's own Project__c object. Other than the inspection tools flagging it everything compiles and runs fine.

[Scott Wells]

Ah, okay. And yes, these inspections errors are raised 100% by IC's own parser and type inference engine. When there are false negatives, it's a bug I need to address. And that's always fun given how...quirky...Apex is as a language. I'll keep trying to reproduce it given the info you've provided. I'll let you know if I have any problems. Thanks for all the details!

[Scott Wells]

John, before I dig into this, quite a large number of fixes have occurred in this area. Would you mind seeing if the problem is still reproducible? Thanks!

[John De Santiago]

Hi Scott, I made sure I was on the latest version of everything and opened up the project that had this scenario and it does appear to still be an issue.

Again, it's not preventing me from doing anything it just shows up as a conflict it can't resolve in the editor.

[Scott Wells]

Thanks for checking, John. That's all I needed to know. I don't mind jumping in and reproducing/fixing it, but it sounded very similar to a few things I'd already fixed so I figured it was worth checking before digging in. Thanks again!

[Scott Wells]

John, I've obviously let this languish for much too long and wondered if you could confirm what I'm actually debugging with me. The simple attempts to reproduce this aren't forcing the error. Reviewing the comments, it looks like we suspected that the underlying problem was IC incorrectly resolving to the wrong Project__c object when you had a local one and one from a managed package (that should require namespace qualification to be resolved properly). Is that correct?

Or perhaps another question would be whether this problem still occurs for you. I have implemented a large number of fixes in this area since early March. If it does, please help refresh my memory on the exact nature of it so that I can take care of it finally. Thanks!

[Scott Wells]

Never mind...I was able to reproduce it by modeling a local custom object with the same name as a custom object from an installed managed package. Shame on me for not doing that before now!

[Scott Wells]

Fix submitted for inclusion in the next build.

[John De Santiago]

Hi Scott, Sorry I wasn't able to respond sooner I was out of town this past weekend. But looks like you were able to reproduce the issue. Let me know if you need me to do any testing on my end.

[Scott Wells]

Oh, no problem. I'll be posting the new build shortly (in the next hour most likely). Once you update just let me know if the issue still exists for you.

[Scott Wells]

Delivered in 2.0.3.0 and 1.8.3.6.