I have a functioning Excel macro that always produces a Rubberduck parse Error.
When I click the icon to view the parse errors, the search results box is empty

Version 2.0.13.32288
Would it be possible for you to share the macro that produces the parse error so we can see if we can reproduce either issue?
sorry, I wish I could. it's got a lot of private details baked in that my company wouldn't be happy if I shared. could I provide some stats on it? is there particular code or structures that are known to cause errors?
@connerk are you using vbWatchDog? There's a known issue with processing member attributes of vbWatchdog's generated code. Other than that.. Do you have logging enabled? The logs would have exception details that could be useful.
not using vbWatchDog. I do use MZ-Tools but even if I unload it Rubberduck still gives me a parsing error.
I've just created a macro with one module, containing
[function addTwoNumbers(a,b) as double] => obvious code
Rubberduck did not give me a parse error.
I then added a test module through the Rubberduck dropdown, reparsed and got a parse error.
if I remove the test module, the parse error persists.
if I close and re-open, the error persists.
I have not turned on logging. I see it in the settings and will see what I can get from it.
I suspect an IOException (or something derived from it) in the preprocessing stage - logs can get very verbose at TRACE level, but they also tell us the most about the sequence of events. We use NLog for logging, it handles all the archiving automatically, and we set it up to clear the current log everytime RD starts, which works well for diagnosing issues.
ok! Here are logs from when I click the refresh button in the ribbon.
actual application:
RubberduckLog.txt
simple 1 module with addTwoNumbers() function
RubberduckLog.txt
The first log is relevant to the parse error and point to line 746, column 23 of module "AppVariables". It looks like it's failing on some sort of declaration. Are there a couple lines around there that can be shared? If not, how about the same syntax with only the variable names \ literal values changed?
The second log is a bit more puzzling - from that one it looks like we tried to load a library from a referenced project or library, but couldn't load it because the typelib wasn't registered. I'm not exactly sure how that's possible if VBA is able to open and compile it.
Do you reference anything that isn't a library? For example, an .xlam file?
Do you reference anything that isn't on the local machine - i.e. a registered library from a network share?
Do you have any of the Rubberduck COM APIs referenced?
Here is the whole thing with the lines in tact, redacted where necessary.
this entire module is global variables. my ego insists that I notify you that this is legacy code I maintain. :)
AppVariables.txt
if is RD looking at the first line as "Attribute VB_Name = "AppVariables"" then line 746 is
"Public arySV(300, 7) As Variant"
column 23 is where there is a double space before "As Variant"
I'm surprised that VBE didn't remove the extra space here.
if I remove the excess space I still get a parse error.
this doesn't explain what is causing the error in the addTwoNumbers() project though..
I'll keep poking through the log
and thanks for the help!
If I had to guess, I'd guess the grammar thinks that Public arySV(300, 7) As Variant should have a Sub or Function or something in there.
@Hosch250 sorry, I don't think that's it. That's a static array declaration not a method. there are 33 of them in this module
@connerk - We've had issues with the potential ambiguity in the VBA grammar between array subscripts and procedure argument lists. I'm pretty sure it's some combination of multi-dimensional fixed array, Public declaration, and "strong" (or in this case explicit) typing.
Thanks for providing the file - that helps tremendously.
I pasted that entire file into Excel, and everything works as expected.
@comintern
just saw these questions:
Referring to the actual project:
_Do you reference anything that isn't a library? For example, an .xlam file?_ => NO
_Do you reference anything that isn't on the local machine - i.e. a registered library from a network share?_ => NO
_Do you have any of the Rubberduck COM APIs referenced?_ => late bound RubberDuck.AssertClass
if I open a brand new book (no modules):
refresh => success
add test method through RD menu, early binding => parse error
RubberduckLog.txt
not a line of code actually typed on that one. just the "add test module" button pressed.
the same above but with late bound unit test => success
RubberduckLog.txt
Huh wtf
2017-03-21 10:26:34.8598;ERROR-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 13).;System.Runtime.InteropServices.COMException (0x8002801D): Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
at Microsoft.Vbe.Interop.Reference.get_FullPath()
at Rubberduck.VBEditor.SafeComWrappers.VBA.Reference.get_FullPath() in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\SafeComWrappers\VBA\Reference.cs:line 45
at Rubberduck.VBEditor.QualifiedModuleName.GetProjectId(IReference reference) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\QualifiedModuleName.cs:line 31
at Rubberduck.Parsing.VBA.ParseCoordinator.GetReferenceProjectId(IReference reference, IReadOnlyList`1 projects) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 804
at Rubberduck.Parsing.VBA.ParseCoordinator.GetReferencesToLoadAndSaveReferencePriority(IReadOnlyList`1 projects) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 912
at Rubberduck.Parsing.VBA.ParseCoordinator.SyncComReferences(IReadOnlyList`1 projects, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 841
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(ICollection`1 toParse, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 201
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 749
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 682
2017-03-21 10:26:34.8784;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState raised StateChanged (Error);
2017-03-21 10:26:35.0915;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run finished after 0s. (thread 13).;
Looks like we need the COM collector to skip anything it can't load - whatever the reason is.
should I re-install maybe?
is it System.Runtime.InteropServices.COMException that is not registered?
Nah, I don't think it would fix anything - looks like Rubberduck doesn't like loading its own type library at runtime; we have a plan to use actual .net reflection to pull the COM-visible declarations from Rubberduck.dll instead of loading the Rubberduck.tlb referenced type library: this is a known (but intermittent and not really explained) issue with parsing a project that has an early-bound reference to Rubberduck's API.
A reinstall probably won't help, although we've also run into a couple instances where RD has difficulty loading its own typelib with a LoadLibrary call. Linking #2789
ah. seems like if it has Ever been early bound it will error ever after. I dont' see any RD in the references

and have ensured all assertClass's are late bound. still getting the parse error
2017-03-21 10:38:05.6380;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState raised StateChanged (ResolvingReferences);
2017-03-21 10:38:05.8944;ERROR-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 14).;System.InvalidCastException: Unable to cast object of type 'Rubberduck.Parsing.Symbols.ProjectDeclaration' to type 'Rubberduck.Parsing.Symbols.ClassModuleDeclaration'.
at Rubberduck.Parsing.Symbols.TypeHierarchyPass.AddImplementedInterface(Declaration potentialClassModule) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\Symbols\TypeHierarchyPass.cs:line 55
at Rubberduck.Parsing.Symbols.TypeHierarchyPass.Execute() in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\Symbols\TypeHierarchyPass.cs:line 36
at Rubberduck.Parsing.VBA.ParseCoordinator.<>c.<ExecuteCompilationPasses>b__46_0(ICompilationPass p) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 571
at System.Collections.Generic.List`1.ForEach(Action`1 action)
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCompilationPasses() in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 571
at Rubberduck.Parsing.VBA.ParseCoordinator.ResolveAllReferences(ICollection`1 toResolve, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 520
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(ICollection`1 toParse, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 243
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 749
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 682
2017-03-21 10:38:05.9079;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState raised StateChanged (Error);
2017-03-21 10:38:06.1469;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run finished after 17s. (thread 14).;
2017-03-21 10:38:07.8358;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;(52218704) Executing click handler for commandbar item '', hash code 6168214;
2017-03-21 10:38:07.8451;TRACE-2.0.13.32288;Rubberduck.UI.DockableToolwindowPresenter;Initializing Dockable Panel (SearchResultsDockablePresenter);
2017-03-21 10:39:44.6577;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(44274261) Executing click handler for menu item 'S&ettings', hash code 42383293;
@connerk hmm this looks like a bug in the declaration finder (well in the TypeHierarchyPass anyway) - could the project happen to be named exactly as one of the class modules under it?
FWIW I pasted AppVariables.txt in a new module and it parsed without any issues here. arySV is recognized as a Variant, but it seems to fail to recognize it as an array:

Compare to:

From:
vb
Sub DoSomething()
Dim foo()
End Sub
When a variable is recognized as an array, the commandbar text for it includes () parentheses.
all names look unique

if I put AppVariables into a fresh workbook I also don't get a parse error.
be advised though, I did fix the "[double space] As Variant" script though
if I add the extra space back it still doesn't error
The double space shouldn't matter, our grammar is (mostly) written against the VBA language specifications, not against what the VBE turns processed code into (although we do have a few hacks that rely on it).
I'm positively confused now.
csharp
private void AddImplementedInterface(Declaration potentialClassModule)
{
if (potentialClassModule.DeclarationType != DeclarationType.ClassModule)
{
return; // this guard clause SHOULD prevent the InvalidCastException you're seeing
}
var classModule = (ClassModuleDeclaration)potentialClassModule;
foreach (var implementedInterfaceName in classModule.SupertypeNames)
{
var expressionContext = _expressionParser.Parse(implementedInterfaceName);
var implementedInterface = _bindingService.ResolveType(potentialClassModule, potentialClassModule, expressionContext);
if (implementedInterface.Classification != ExpressionClassification.ResolutionFailed)
{
classModule.AddSupertype(implementedInterface.ReferencedDeclaration);
((ClassModuleDeclaration)implementedInterface.ReferencedDeclaration).AddSubtype(classModule); // << line 55
}
else
{
Logger.Warn("Failed to resolve interface {0}.", implementedInterfaceName);
}
}
}
Looking again, it looks like we're making an assumption here, that ResolveType returns a ClassModuleDeclaration (and it should):
csharp
var implementedInterface = _bindingService.ResolveType(potentialClassModule, potentialClassModule, expressionContext);
We need to look at ResolveType and restrict its scope to class modules, it makes no sense that a type resolves to a project declaration.
@connerk Can you tell us the names of the interfaces/classes your classes and forms implement? That might help a lot to understand what is going wrong here.
sorry, I'm lost on the terminology there..
when I make a completely empty workbook, add a RD test module with early binding, the error occurs.
it's the same error given with real application.
at that time the only referenced libraries are whatever VBA adds automatically and RD
no COM or Excel add-ins other than RD are active. (to my awareness!)
https://www.dropbox.com/s/ci0cxhtwajprfbo/RubberDuck%20Parsing%20Error%20Workbook_Simple.xlsm?dl=0
Log File:
RubberduckLog.txt
I think we have multiple issues combined in this one.
I was looking into the issue in your last log file, the one with the error in the TypeHierarchyPass. (This compilation pass processes the Implements statements in classes and forms.)
Does this error occur in the empty workbook with only the test module or is there another error in the log in that case?
That's the path on the machine RD was built on.
I assumed that. so it's ok that it's in my log file? it's not referring to a file location it's looking for?
I have the same issue with Access VBA. I set it to Early binding one time in a project, I've since switched back to Late binding, but I still have an empty parse error in that project I can't get rid of. Is there a work around to get this working again before an update? It's one of my major dev projects.
Here's the error log with minimum log level set to Info (Let me know if you need me to set it to anything else). Thanks!!
PS. I created a GitHub account just to post this, so If I'm doing something wrong, please let me know.
@gbalcom thanks for that! The exception details are pointing to a library not registered error - are there any broken references in the project?
We need to make that message mention the path it was trying to work with...
2017-04-05 12:38:34.6292;ERROR-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 133).;System.Runtime.InteropServices.COMException (0x8002801D): Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
at Microsoft.Vbe.Interop.Reference.get_FullPath()
at Rubberduck.VBEditor.SafeComWrappers.VBA.Reference.get_FullPath() in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\SafeComWrappers\VBA\Reference.cs:line 45
at Rubberduck.VBEditor.QualifiedModuleName.GetProjectId(IReference reference) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\QualifiedModuleName.cs:line 31
at Rubberduck.Parsing.VBA.ParseCoordinator.GetReferenceProjectId(IReference reference, IReadOnlyList`1 projects) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA
While you're here, feel free to be our 339th star!
I don't think so, but how would I know for sure? my code compiles fine. Here are my references.
hmmm.....ok. I unchecked OLE Automation & Acrobat Access 3.0 Type Librarys (without hitting OK), checked them again and hit OK. Now it's working again.
@gbalcom If you've switched your test code to late-bind to the Rubberduck type library, you can remove that reference - you don't need it for late-binding.
ah, ok that makes sense. Thanks @retailcoder !
Hello everyone. I'm currently experiencing and reproducing the problems related to early-binding as well.
Here is a minimal (not) working example with the corresponding log file. (packed into a .zip file, as GitHub refused to let me upload a .xlsm file)
The log is produced by opening the .xlsm file, and selecting RD's refresh/parse button. If I then switch to late-bound Rubberducking, it starts parsing correctly the moment I remove the reference to Rubberduck.tlb
Contents of log file (should be well known by now):
2017-05-05 15:42:13.0501;INFO-2.0.13.32288;Rubberduck.App;Rubberduck version 2.0.13.32288 loading:
Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1 x64
Host Product: Microsoft Office 2010 x86
Host Version: 14.0.7176.5000
Host Executable: EXCEL.EXE;
2017-05-05 15:42:13.4431;INFO-2.0.13.32288;DynamicInjectora31b97c0ff7f41f2b2d0f26e48d136d4;Executing version check.;
2017-05-05 15:42:40.9377;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;(42927366) Executing click handler for commandbar item 'Pending', hash code 65748423;
2017-05-05 15:42:40.9377;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run started. (thread 10).;
2017-05-05 15:42:41.0567;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'Tabelle1' state is changing to 'Pending' (thread 14);
2017-05-05 15:42:41.0567;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'DieseArbeitsmappe' state is changing to 'Pending' (thread 10);
2017-05-05 15:42:41.0567;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'TestModule1' state is changing to 'Pending' (thread 7);
2017-05-05 15:42:41.0727;ERROR-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 10).;System.Runtime.InteropServices.COMException (0x8002801D): Bibliothek nicht registriert. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
at Microsoft.Vbe.Interop.Reference.get_FullPath()
at Rubberduck.VBEditor.SafeComWrappers.VBA.Reference.get_FullPath() in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\SafeComWrappers\VBA\Reference.cs:line 45
at Rubberduck.VBEditor.QualifiedModuleName.GetProjectId(IReference reference) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.VBEEditor\QualifiedModuleName.cs:line 31
at Rubberduck.Parsing.VBA.ParseCoordinator.GetReferenceProjectId(IReference reference, IReadOnlyList`1 projects) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 804
at Rubberduck.Parsing.VBA.ParseCoordinator.GetReferencesToLoadAndSaveReferencePriority(IReadOnlyList`1 projects) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 912
at Rubberduck.Parsing.VBA.ParseCoordinator.SyncComReferences(IReadOnlyList`1 projects, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 841
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(ICollection`1 toParse, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 201
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 749
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\Users\Mathieu\Documents\GitHub\Rubberduck (main)\Rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 682
2017-05-05 15:42:41.0777;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState raised StateChanged (Error);
2017-05-05 15:42:41.1567;DEBUG-2.0.13.32288;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run finished after 0s. (thread 10).;
2 rather general questions on the side:
@Inarion re your questions:
neither ... it's an artifact of how C# is compiled and linked. When the stacktrace is created the location of the class on the system of whoever built it will be put as the location of the class. Since retailcoder built the release you're working with, it's paths from his system.
It's good that the build works that way, it's possibly a bit annoying because it means an information leak ...
It's fine to yell "Me too, plz fix", it's even better to contribute something (like you did) by providing additional information. On that note: Github has introduced "reactions"-emoji, that you can put on any comment to indicate agreement, which is almost as effective and significantly less noisy than commenting ":+1: I also haz this problem. Plz fix!" :smile:
I am experiencing several issues that seems similar enough for me to post here.
Issue 1) I have a parse error continually appearing at the top rhs.
Issue 2) Unit test returning Test raised an error. Exception from HRESULT: 0x800A9C68.
Issue 3) RubberDuck reference sometimes loads, often doesn't.
Set-up:
I have one workbook open with one module. In the module i have the following code:
`
Public Function whatever(ByRef number As Integer) As Long
If Len(number) > 0 Then
whatever = number + 1
End If
End Function`
In the Unit Test i have the added in only to the following:
`'@TestMethod
Public Sub TestMethod1() 'TODO Rename test
On Error GoTo TestFail
'Arrange:
Dim result As Long
'Act:
result = whatever(1)
'Assert:
' Assert.AreEqual 2, result
TestExit:
Exit Sub
TestFail:
Assert.Fail "Test raised an error: #" & Err.number & " - " & Err.Description
End Sub`
I am using strict assert with early binding options.
Originally, the test was running and saying Inconclusive 2, result different types.
Now i am getting the following:
Test raised an error. Exception from HRESULT: 0x800A9C68.
The function can be called from an ordinary procedure just fine but is hitting the test fail line in the Unit Test.
Nothing is being written to the debug log.
Present are additional projects ATPVBEAN.XLAM, SOLVER.XLAM, FUNCRES.XLAM.
Any advice please on how to resolve? Apologies i can't seem to get code aligned.
Could you please tell us what is in you Rubberduck log file? There is a button leading you to the log directory in the Rubberduck settings.
An empty parser error most likely indicates that there has been an unexpected exception during the parsing process.
There is nothing in the log file at present even though it is set to debug level.
UPDATE:
1) The reference to RubberDuck is still not showing. This i would still like help with please.
2) No parse error message at present. Don't know if related to lack of reference.
3) Solved different types message using CLong conversion. I was being stupid!
Hang on. Now with similar test as i closed Excel and re-opened i have:
1) A log file (attached)
2) No reference is loaded for RubberDuck so no intellisense
3) Original message is back saying of different types.
4) No parse error appearing!
I would really like to be able to ensure reference library loads.
Additional side-point is that when reference was loading it had to be unchecked for the test to be found when clicking the refresh in test explorer. When the test ran it added itself back in. But, currently not appearing at all even when opening Excel anew.
RubberduckLog.txt
Should i post this elsewhere as it currently seems to be an issue with loading the RubberDuck reference into references? Is so, is there an appropriate place you could suggest please?
I have added the reference in by browsing to the file: Rubberduck.tlb
However, now the parse error immediately appears again irrespective of anything else being present. Add reference = get parse error.
@quentinharris nah it's fine, that's a known problem - for some reason loading Rubberduck.tlb with Rubberduck.dll to iterate the exposed COM types causes the COM declaration collector to blow up. We're planning on skipping the loading of that particular library and getting the declarations through .net reflection instead, so that the parser won't try to load Rubberduck.tlb at all and still know about the exposed COM types.
The interim solution is unfortunately to stick to late-binding with Rubberduck.tlb, whenever that problem happens.
Ok. Many thanks. Is this an allocated development item that i can track?
I'm having the same problem. The ducks just spin and spin. I updated to the latest version of Rubberduck which may have been a mistake.
Currently parsing my code doesn't work at all. I'm not sure what it's hanging on. This is from my logs:
2018-02-20 10:38:19.2911;ERROR-2.1.2.2849;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 51).;System.Runtime.InteropServices.COMException (0x80004005): The expression you entered refers to an object that is closed or doesn't exist.
at Microsoft.Vbe.Interop._VBComponent.get_Properties()
at Rubberduck.VBEditor.SafeComWrappers.VBA.VBComponent.get_Properties() in C:\projects\rubberduck\Rubberduck.VBEEditor\SafeComWrappers\VBA\VBComponent.cs:line 24
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.SupertypeForDocument(QualifiedModuleName module, RubberduckParserState state) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 148
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.AddSupertypesForDocumentModules(IReadOnlyCollection`1 modules, RubberduckParserState state) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 124
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.ResolveReferences(IReadOnlyCollection`1 toResolve, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 81
at Rubberduck.Parsing.VBA.ParsingStageService.ResolveReferences(IReadOnlyCollection`1 toResolve, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParsingStageService.cs:line 95
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(IReadOnlyCollection`1 toParse, IReadOnlyCollection`1 toReresolveReferencesInput, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 254
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 378
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 313
@alexkadis Do you mean version 2.1.2.2850-pre when you say "Latest"? Could you try opening all modules in the VBE and reparse? See also #3753
Note that while I wrote this message, The release 2.1.2.2851-pre was finished :)
@Vogel612 looks like @alexkadis downloaded .2849 just as I was merging .2850 (the CI build for .2851 completed just now); .2849 was the PR reinstating content hash computation on the QMN's, .2850 was the weak-reference COM safe PR, and .2851 fixes the SLL parser mode for array declarations with extraneous whitespace.
@Vogel612 I have v2.1.2.2849-pre. I can install .2851 if that's helpful.
Here's the logs after opening up all of the code:
2018-02-20 10:46:08.3742;ERROR-2.1.2.2849;Rubberduck.Common.LogLevelHelper;
Rubberduck version 2.1.2.2849 loading:
Operating System: Microsoft Windows NT 10.0.16299.0 x64
Host Product: Microsoft Office 2013 x64
Host Version: 15.0.4963.1000
Host Executable: MSACCESS.EXE;
2018-02-20 10:47:42.6106;ERROR-2.1.2.2849;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 16).;System.Runtime.InteropServices.COMException (0x80004005): The expression you entered refers to an object that is closed or doesn't exist.
at Microsoft.Vbe.Interop.VBComponentClass.get_Properties()
at Rubberduck.VBEditor.SafeComWrappers.VBA.VBComponent.get_Properties() in C:\projects\rubberduck\Rubberduck.VBEEditor\SafeComWrappers\VBA\VBComponent.cs:line 24
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.SupertypeForDocument(QualifiedModuleName module, RubberduckParserState state) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 148
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.AddSupertypesForDocumentModules(IReadOnlyCollection`1 modules, RubberduckParserState state) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 124
at Rubberduck.Parsing.VBA.ReferenceResolveRunnerBase.ResolveReferences(IReadOnlyCollection`1 toResolve, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ReferenceResolveRunnerBase.cs:line 81
at Rubberduck.Parsing.VBA.ParsingStageService.ResolveReferences(IReadOnlyCollection`1 toResolve, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParsingStageService.cs:line 95
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(IReadOnlyCollection`1 toParse, IReadOnlyCollection`1 toReresolveReferencesInput, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 254
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 378
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 313
@alexkadis thanks! make sure you uninstall the previous build through control panel's add/remove programs first :smile:
.2851 addresses an edge case that hindered parser performance, but .2850 has implications that _may_ affect this issue (one way or another). Let us know how it goes!
@rubberduck-vba/dev from the stack trace, it looks like it blew up trying to determine the base/super type for a document module - this is something @WaynePhillipsEA's API can address.
@retailcoder I uninstalled using add/remove programs and installed .2854 (latest as of this comment).
I decided to change the log-level to debug and some more interesting information showed up. It seems the [ character (left square bracket) is causing Rubberduck to hang?
The full RubberduckLog.txt
I don't want to bother posting all of my code (kinda useless without the database and I can't share that), but here's a snippet:
Module:
Form_Home (a Form called "Home")
Line 46 of the attached debug log:
2018-02-21 13:57:09.8461;DEBUG-2.1.2.2854;Rubberduck.Parsing.VBA.VBAModuleParser;SLL mode exception;Rubberduck.Parsing.Symbols.ParsingExceptions.MainParseSyntaxErrorException: mismatched input '[' expecting {<EOF>, ':', REM, NEWLINE, ''', WS, LINE_CONTINUATION} ---> Antlr4.Runtime.InputMismatchException: Exception of type 'Antlr4.Runtime.InputMismatchException' was thrown.
at Antlr4.Runtime.DefaultErrorStrategy.Sync(Parser recognizer)
at Rubberduck.Parsing.Grammar.VBAParser.endOfStatement() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\VBAParser.cs:line 19574
The relevant code:
LN CODE
24 Private Sub NewBatchButton_Click()
25 DoCmd.Close
26 If CurrentProject.AllForms("DetailsBatch").IsLoaded Then
27 DoCmd.GoToRecord acDataForm, "DetailsBatch", acNewRec
28 Forms![DetailsBatch].SetFocus
29 Else
30 DoCmd.OpenForm "DetailsBatch", acNormal, , , acFormAdd
31 End If
32 End Sub
Also worth noting that the biggest things I changed before all of this started happening:
@alexkadis This isn't relevant to the bug report but I would point out that there is a workaround -- use Forms("DetailsBatch").SetFocus instead.
I am aware there are several code samples where they might suggest using a bang operator to get a member from the collection but I personally think it should be avoided because it's more likely to hide potential compile-time errors, and turn those into a run-time errors, which only increase the debugging effort.
Mind you, Rubberduck will need to get smart with that kind of syntax, so it should be fixed eventually. But if you don't want to wait for it, the workaround suggested can help you out.
@bclothier Thanks! Didn't know that, I've made some updates to my code, and I'm guessing that the remaining errors are relevant.
This was already reported in this issue: #3753, and there has been already a PR that should have fixed it. Can you make sure you've updated the version of Rubberduck? I see that you are using 2.1.2.2854 - which already includes this PR. So apparently this didn't fix the issue completely.
@bclothier Yup, using 2.1.2.2854.
Are the two issues related or just a coincidence that I'm experiencing both? #3753 is in the logs, but in the UI, rubberduck hanging on "Parse Error" (this issue)
AIUI, they are same error, just a slightly different symptoms.
@alexkadis Regarding the DEBUG entry in your Rubberduck log, this does not mean that we could not parse the code; only the SLL mode failed and we retried using LL. Since the remaining entries you have posted do not contain a corresponding ERROR level log, the LL parsre succeeded.
Let me provide a bit of background here. We use two diffferent parsing strategies, the fast but restricted SLL strategy and the powerful but slower LL strategy. The two most important differences between the two are that the SLL parser cannot revert any decision about what a subrule matches and that the subrules are matched without context. This can make subrules match too much or let it take the wrong of two alternatives possible on first sight. Then it errors out. The LL strategy will basically revert its decisions and come to the correct conclusion, which is identical to the SLL one if the SLL strategy succeeds. So, our approach is to first try SLL mode, which works almost always, and fall back to LL mode if it did not work. This is also the reason why the SLL error is only DEBUG level, but the LL error is ERROR level.
Regarding the remaining warnings, it seems that Rubberduck has not been able to identify some constants and types from referenced libraries, which we will have to look into. This is basically the problem from your issue #3762.
The final ERROR log entry is what makes your parse fail. Whenever we encounter an unexpeted exception wile parsing, we set the ParserError state to deactivate most features; Rubberduck is not in a usable state is that happens. The specific error encountered here is indeed the same as in #3753, which is a painful issue with the VBE's own API. However, this particular point should be fixed once PR #3778 gets merged.
Ignore the earlier version of my comment. While .2869 didn't resolve the issue, .2870 did! Thank you all
@alexkadis just to clarify - the PR 3778 actually got merged into .2870 which was why .2869 didn' t work. Glad to get confirmation it did!
@bclothier perhaps I spoke too soon... When opening Access for the first time, no error. But if I run Compact & Repair, the error is back:
2018-02-22 15:28:18.9582;ERROR-2.1.2.2870;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 14).;System.Runtime.InteropServices.COMException (0x80010105): The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
at Microsoft.Vbe.Interop.VBProjectClass.get_Protection()
at Rubberduck.Navigation.CodeExplorer.CodeExplorerProjectViewModel..ctor(FolderHelper folderHelper, Declaration declaration, IEnumerable`1 declarations) in C:\projects\rubberduck\RetailCoder.VBE\Navigation\CodeExplorer\CodeExplorerProjectViewModel.cs:line 37
at Rubberduck.Navigation.CodeExplorer.CodeExplorerViewModel.<HandleStateChanged>b__51_2(IGrouping`2 grouping) in C:\projects\rubberduck\RetailCoder.VBE\Navigation\CodeExplorer\CodeExplorerViewModel.cs:line 319
at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Rubberduck.Navigation.CodeExplorer.CodeExplorerViewModel.HandleStateChanged(Object sender, ParserStateEventArgs e) in C:\projects\rubberduck\RetailCoder.VBE\Navigation\CodeExplorer\CodeExplorerViewModel.cs:line 318
at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
at Rubberduck.Parsing.VBA.ParseCoordinator.ExecuteCommonParseActivities(IReadOnlyCollection`1 toParse, IReadOnlyCollection`1 toReresolveReferencesInput, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 244
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAllInternal(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 378
at Rubberduck.Parsing.VBA.ParseCoordinator.ParseAll(Object requestor, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ParseCoordinator.cs:line 313
That is a separate issue. Can you please open a new issue?
Most helpful comment
@alexkadis Regarding the DEBUG entry in your Rubberduck log, this does not mean that we could not parse the code; only the SLL mode failed and we retried using LL. Since the remaining entries you have posted do not contain a corresponding ERROR level log, the LL parsre succeeded.
Let me provide a bit of background here. We use two diffferent parsing strategies, the fast but restricted SLL strategy and the powerful but slower LL strategy. The two most important differences between the two are that the SLL parser cannot revert any decision about what a subrule matches and that the subrules are matched without context. This can make subrules match too much or let it take the wrong of two alternatives possible on first sight. Then it errors out. The LL strategy will basically revert its decisions and come to the correct conclusion, which is identical to the SLL one if the SLL strategy succeeds. So, our approach is to first try SLL mode, which works almost always, and fall back to LL mode if it did not work. This is also the reason why the SLL error is only DEBUG level, but the LL error is ERROR level.
Regarding the remaining warnings, it seems that Rubberduck has not been able to identify some constants and types from referenced libraries, which we will have to look into. This is basically the problem from your issue #3762.
The final ERROR log entry is what makes your parse fail. Whenever we encounter an unexpeted exception wile parsing, we set the ParserError state to deactivate most features; Rubberduck is not in a usable state is that happens. The specific error encountered here is indeed the same as in #3753, which is a painful issue with the VBE's own API. However, this particular point should be fixed once PR #3778 gets merged.