Rubberduck: Parser gets stuck on "Loading references" with certain references

[rossorp]

I have installed the v2 Alpha 1 version (build 2.0.0.2650) and when I open a project that contains certain references, or add a reference and then click the "Parse all opened projects" button, it gets stuck at "Loading references".

To reproduce:
If I open a new workbook, open the VBE, add a new module to Book1 (the new workbook), and click on the parse all button then it will parse ok and say "Ready". If I then, in this same workbook, add a reference to the Microsoft Scripting Runtime, for example, and then click on the parse button, it stops at "Loading references".

For reference I am on Windows 7 running 32-bit Excel 2010.

[retailcoder]

If you open a macro-enabled workbook that already has a reference to the scripting runtime, _and then_ bring up the VBE, it loads normally, right?

[rossorp]

Yes. Well, at least sometimes. I just opened a file with only the Scripting Runtime added (besides the "defaults") and it has parsed. Other times it hasn't parsed though.

[retailcoder]

I _think_ this will solve itself once the "timing" issue is solved with the RubberduckParserState class, which seems to fire its OnStateChanged event too soon - e.g. it goes to Parsed while one or more modules are still Parsing, or haven't started yet and are still Pending; this causes the resolver task to start resolving identifier references without having the "whole picture", and basically everything that wasn't Parsed when the resolver task started goes under the radar and Rubberduck thinks it's simply not there; if you bring up code inspection results you'll see a bunch of false positives saying "variable not used", "parameter not used" and whatnot.

Right?

[rossorp]

If you are referring to the code inspection results when the parser gets stuck on "Loading references", then when I open the Code Inspections in this state it shows me the previous inspection results, prior to adding the reference and re-parsing, or if I go to update the Code Inspections it doesn't appear to do anything apart from show the loading dots moving in a circle continously (I assume because it is waiting for the parser to finish?).

[retailcoder]

Correct. It's waiting for parser state to report Ready; without all the declarations and identifier references resolved, it won't produce meaningful results. Problem is that parser state gets stuck because of that annoying timing issue. Isn't multithreading fun!

[retailcoder]

Update: good news, it's not a multithreading issue! it's actually a combination of a bug with the way parser state gets evaluated, and a caching issue where "ghost" modules remain cached with a Pending state (as of first pre-release, that would have been LoadingReferences state).

A problem that's understood is halfway fixed!

[ghost]

Also, line 93 in ReferencedDeclarationsCollector throws OverflowExceptions on 64 bit systems because it's using ToInt32 instead of ToInt64. Changing that makes the loading references part fast again.

[retailcoder]

@autoboosh can you make a quick PR with that fix? I'll insta-merge it!

[retailcoder]

I believe this would be fixed, now that parser state is [a little bit] more under control. @Hosch250 any repro with the latest build?

[Hosch250]

No repro.