Parse Error 'Extraneous Input' on unexpected, but valid VBA syntax

[CodeJericho]

Rubberduck version information Version 2.4.1.4627 OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office XP x86 Host Version: 10.0.6771 Host Executable: MSACCESS.EXE

Description Upon opening the VBA Editor and clicking the Rubberduck "Parse" button, Rubberduck completes the parse with a Parse Error on two lines of valid VBA code, both with different, unrecognized syntax.

Parse Error 1: extraneous input '_\r\n ' expecting '-' When I double-click the Parse Error line, it takes me to this line of code:

Section.Parent.Line ((.Left + .Width + SectionProperties.VerticalLineMargin), _
PageHeaderHeight + tmpTopMargin + Abs(Section.Parent.Top)) _
-Step(0, Section.Parent.Height)

and it puts the cursor after the second closing parenthesis in the second line, but before the space and line continuation character

Abs(Section.Parent.Top))| _

The likely issue is that Rubberduck is not understanding the full syntax of the VBA Line method (which does use unconventional syntax), and therefore thinks that the code statement should end after those closing parentheses.

Microsoft VBA Language Docs

Parse Error 2: extraneous input ';' expecting {, ':', REM, NEWLINE, "'", WS, LINE_CONTINUATION} When I double-click the Parse Error line, it takes me to this line of code:

rpt.Print strPre;

and it puts the cursor right before the semi-colon.

For reference, rpt is declared as an Access.Report and strPre is declared as a String, but the real issue appears to be that Rubberduck doesn't think that the semi-colon is valid here, but in this case it is. A semi-colon is a valid separator or line ender when used with the Print method.

StackOverflow explanation

Microsoft VBA Language Docs (see Remarks section)

TheVBProgrammer.com

Expected behavior This is valid VBA and should not generate a Parse Error

[retailcoder]

Thanks for reporting this! :+1:

Indeed, Line syntax is essentially special-cased, both in Rubberduck's and VBA's parsers. Thanks for reporting this! The problem seems to be with the line continuation character though, which we might have forgotten to account for in that specific - I can confirm that the code correctly parses without the line continuations.

https://github.com/rubberduck-vba/Rubberduck/blob/2925035f5210cb7f56792554a43f6e44052acb82/Rubberduck.Parsing/Grammar/VBAParser.g4#L573-L574

A work-around could be to extract the expression into a local variable, and use that variable in the Line statement instead of inlining it (thereby eliminaating the need for a line continuation).

---

The semicolon error is a separate parser issue though. Debug.Print is also a special-cased statement that is hard-coded in the VBA parser and that we need to handle in a "special" way:

https://github.com/rubberduck-vba/Rubberduck/blob/2925035f5210cb7f56792554a43f6e44052acb82/Rubberduck.Parsing/Grammar/VBAParser.g4#L255-L280

Print is a reserved identifier (user code can't define a Print member) - I'm thinking our grammar might need to not hard-code the DEBUG token, but rather allow any identifier in its place... that's a big assumption to make, but I can't think of another way to fix this.

[retailcoder]

Thinking again, rpt.Print being a member call, it really needs to be parsed and resolved as such... but we can't have any member call allow an outputList, it has to be conditional.... @MDoerner does this warrant a predicate? Or is there another way?

[CodeJericho]

If I remove line continuation from each of my Line method calls, the parser now complains:

extraneous input ',' expecting {EOF, ':', REM, NEWLINE, "'", WS, LINE_CONTINUATION} and puts the cursor after the right parenthesis and before the , , B in this line: (and all other such lines)

Me.Line (ctl.Left, ctl.Top)-(ctl.Left + ctl.Width, Me.Height), , B

This is in the Detail_Print event of a Report, where Me is and Access.Report, and ctl references an Access.Control.

Thanks for looking into this. Rubberduck VBA is a game changer. THANKS!

[Vogel612]

please remove one of the commas in that to fix the parser error, we're not parsing nothing as an expression here which would be required because you have an additional comma.

[retailcoder]

@Vogel612 if Line (thing1, thing2)-(thing3, thing4), , B is legal, then our parser rule for it might need to make the last expression optional.

[retailcoder]

So.. to fix the line continuation problem, we could just slip a whiteSpace? before & after the MINUS token, I think.

[Vogel612]

That whitespace should belong to the part of the rule that matches for tuple

[retailcoder]

Closing as fixed - see linked issue #4888 for the Print semicolon bug.