Possible Parser bug; leading commas in Access DoCmd

[A9G-Data-Droid]

Rubberduck version information
Rubberduck version 2.5.0.5384 loading:
Operating System: Microsoft Windows NT 10.0.18363.0 x64
Host Product: Microsoft Office x64
Host Version: 16.0.11929.20648
Host Executable: MSACCESS.EXE;

Description
RD Parser can't handle leading comma in an Acces DoCmd.

To Reproduce
Steps to reproduce the behavior:

1. Use code DoCmd.GoToRecord , , acGoTo, thisRecord
2. Rubberduck Parse
3. ???
4. Crash

Expected behavior
The code is valid, it both compiles and runs. I would not expect this to throw exceptions in the RD parser.

Screenshots
If applicable, add screenshots to help explain your problem.

Logfile
https://github.com/rubberduck-vba/Rubberduck/files/4356946/RubberduckLogREDACTED.txt

Additional context

THIS EXCEPTION:

2020-03-19 13:48:28.5820;DEBUG-2.5.0.5384;Rubberduck.Parsing.VBA.Parsing.TokenStreamParserBase;Rubberduck.Parsing.VBA.Parsing.ParsingExceptions.MainParseSyntaxErrorException: extraneous input ',' expecting {, ':', REM, NEWLINE, ''', WS, LINE_CONTINUATION}

CAUSED BY THIS LINE:
DoCmd.GoToRecord , , acGoTo, thisRecord

[bclothier]

I was able to parse this line just fine.

Can you please try in a new Access file, with only that code and try to parse that? I don't think that is the whole story.

[A9G-Data-Droid]

@bclothier I made a new test DB. I made a single form with a single button. Inside that form it does only this:

Option Compare Database

Private Sub Command5_Click()
    DoCmd.GoToRecord , vbNullString, acNewRec
End Sub

The parser throws 4 exceptions. Two of them correctly cite this line

Token: , at L4C22
Kind of parsed code: CodePaneCode
Component: Form_BS (code pane version)
ParseType: Main parse

While two of the exceptions cite Line 13, which does not exist. There are only 6 lines in this module. It says something about "Exported Version" which might mean something more to you than it does to me.

Token: , at L13C22
Kind of parsed code: AttributesCode
Component: Form_BS (exported version)

This exception doesn't crash RD and the VBE like what is happening in my larger file. So, alas, this may not be the cause of the crash. It's still an unexpected exception, no?

[A9G-Data-Droid]

NOTE: When RD\VBE does hang the parse appears to complete successfully. The icon returns to "Ready" state and does not display an error yet the VBE is unresponsive and must be forcibly closed. Meanwhile the Microsoft Access process is contantly blasting 42% CPU like it's running a marathon.

[MDoerner]

Ok, I have a failing unit test now and I will have to find out what exactly is going wrong here.

Moreover, something seems to be wrong with the error reporting in forms.