Parse Error Search Results empty

[connerk]

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

[alexkadis]

@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:

1. Used Rubberduck's suggestions to make some function/sub variables ByRef, some ByVar
2. Compacted & Repaired
3. Saved the file/closed
4. Updated Rubberduck
5. Reopened project, this is the result.

[bclothier]

@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.

[alexkadis]

@bclothier Thanks! Didn't know that, I've made some updates to my code, and I'm guessing that the remaining errors are relevant.

Remaining errors in log

[bclothier]

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.

[alexkadis]

@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)

[bclothier]

AIUI, they are same error, just a slightly different symptoms.

[MDoerner]

@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.

[alexkadis]

Ignore the earlier version of my comment. While .2869 didn't resolve the issue, .2870 did! Thank you all

[bclothier]

@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!

[alexkadis]

@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

[bclothier]

That is a separate issue. Can you please open a new issue?