1. Scott Wells Avatar Scott Wells
  2. Illuminated Cloud
  3. IlluminatedCloud
  4. Issues

The "Id" field of most objects cannot be resolved

Issue #844 resolved
Derek Wiers created an issue

Screen Shot 2018-01-04 at 11.33.22 AM.png

Screen Shot 2018-01-05 at 10.07.29 AM.png

Screen Shot 2018-01-05 at 10.09.42 AM.png

Screen Shot 2018-01-05 at 10.11.15 AM.png

I've refreshed the OST fully several times, but IC2 really doesn't want to recognize that SObjects have Ids! Additionally, the static methods on the SObject classes aren't recognized as evidenced by the last screenshot. This one's a gnarly one!

Comments (21)

  1. Scott Wells repo owner

    Yeah, I saw this a few days ago. Internally it's because it's not detecting that those SObject stub classes extend SObject and is instead hanging them off of Object. As a result, you won't see the stuff that is inherited from SObject. I can provide the latest build that I'm planning to release next week if you'd like to see if that resolves the issue for you. Note that while I've been using it as a daily driver, I haven't gone through a full hardening phase on it so you might find other (hopefully minor) issues. Let me know if you'd like to try it and I'll attach it here.

  3. Scott Wells repo owner

    Sure. Here you go. Note that you'll want to regenerate the OST after installing this as I've had to massage it quite a bit to fix a host of other issues that were leading to code inspection false negatives/positives. Let me know whether it helps address this issue or not, and of course whether it raises other issues.

    This build enhances the illegal assignment inspection for just about every place where type can be inferred: invocation args vs. param types, operands of various operators, statement constructs such as if/while/for/do-while conditions, throw/catch exceptions, etc., and it eliminates a number of false negatives from the unused declaration inspection.

  5. Scott Wells repo owner

    Glad to hear. Like I said, let me know if you see any new issues (bugs, degraded performance, etc.) from the build. I'm going to be profiling and hardening it over the weekend with the goal of releasing on Monday or Tuesday, so any early feedback is greatly welcomed!

  7. Scott Wells repo owner

    Okay. I'll need to take a close look over the weekend then. I'm stuck in a series of meetings today and won't free up until the end of the work day. What you may be able to do is disable the a few of the code inspections to see if that helps in the interim. Obviously 100% not what I want to tell you since code inspections are one of the tentpole features of IC2, but it may help to resolve concrete SObject types to the correct inheritance hierarchy until I can provide the proper fix to you.

    I may post a new build with some additional logging or even a prospective fix over the weekend for you to try out if you don't mind since this is occurring pretty reliably in your project. I'll keep you posted as I work through it. So sorry for the issue, but rest assured I'll get it resolved ASAP.

  8. Derek Wiers reporter

    fun fact, that was after an SObject-only OST refresh (I had already done a full one after upgrading to your pre-release, and had just added a field to the org that I wanted reflected in the IDE). The editor didn't necessarily freeze after it was done, but it didn't prompt for project reload either, and I couldn't type - I could select text but couldn't edit it. It was weird. So I restarted the IDE manually and the above is what I found. I'm running a full OST refresh now.

  10. Scott Wells repo owner

    I think the root cause is a relatively recent regression around how inheritance hierarchies are processed. Something seems to happen differently if files involved in the hierarchy are in open editors when the indices are being built. Luckily I have a reproducible test case around this already and plan to use that to debug and fix it this weekend. It's also affecting the incomplete concrete class inspection.

  12. Scott Wells repo owner

    Okay, this should be the fix. And it was a very recent regression where I tried to implement a recursion guard for folks who accidentally created mutually-recursive inheritance relationships but the implementation was flawed and was omitting some valid relationships. Please let me know if this doesn't resolve the issue for you completely. I'm going to shoot for a release with this Monday morning if possible.

  13. Scott Wells repo owner

    Hopefully this is fully resolved in 2.0.0.6. Please let me know if you continue to see the issue at all after updating.

  16. Derek Wiers reporter

    Actually, gimme a sec. This might have been my fault...(I forgot I refreshed my sandbox recently and may not have hooked up IC since...)

  18. Scott Wells repo owner

    No problem. Keep me posted. If you're good to go, wonderful. If not, it's mine to address.

  19. Derek Wiers reporter

    Screen Shot 2018-01-16 at 11.09.08 AM.png

    Phew! All fixed. Closing this back up. Sorry for the false alarm. Oddly enough, I did have to regen my OST twice. Thought that was odd, but hey, all fixed now! Must have just been in a "state of funk". Hopefully that cleared it out.

  20. Scott Wells repo owner

    Okay. That is weird that you had to regent twice. We're both full regens? That should be a consistent operation. Partial regens update in-place and can lead to minor differences. For example, you won't see deletes reflected there. If you see that behavior again, please let me know.

  21. Derek Wiers reporter

    Yeah, they're full regens. I "reset" the connection so that it would authenticate to the new org, then kicked off an OST regen manually. Once that was done, I reloaded the project, and it complained that it was in an invalid state, so I regen'd the OST again (assuming full, but it didn't actually give me a choice)

  22. Log in to comment
Assignee
–
Type
bug
Priority
blocker
Status
resolved
Component
Code Inspections and Intentions
Version
2.0
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!