Parse Error when Sub has no end sub line
For example, a module with only the following:
Option Explicit
Sub Macro1()
Will generate a parse error
That's pretty much by design... What else should it do? Most RD features require or assume that the code is compilable. If the VBE can't understand it, neither can Rubberduck.
Would be at least convenient if RD could highlight the sub heading that's causing the parse error so the user can resolve the issue. I think this was suggested here also:
https://github.com/rubberduck-vba/Rubberduck/issues/3527
Edit: Seems to be more an issue of me not understanding how to resolve the parse error through the parse error window.
got this when i tried to reproduce
Module3 | Module | L5C12 | no viable alternative at input '
-- | -- | -- | --
which should be sufficient
Thanks
To put it another way: given a parse error, either the code can compile & run and we have a parser bug (there's a handful unhandled edge cases), or the code can't compile and won't run.
Alt+D,Enter (i.e. debug/compile) will have the VBE tell you where the problem is if it's a compile error, otherwise you can usually click the little 'x' icon to display the actual parser error; that's the toolwindow being referred to in the linked issue - it already exists :smiley:
Parser errors are generated by the parser, which is itself generated by Antlr4 - we don't control these error messages - we technically could and probably will one day, but customizing every possible parse error for every single grammar rule in the language is a lot of work!
L5C12 tells you the position of the error token; "no viable alternative at EOF" means the parser has encountered an unexpected EOF token (i.e. reached the end of the module), and since the grammar rule it was working with (that would have been the rule that defines the syntax for a Sub statement) doesn't have any alternative (a block of code, or an End Sub token) that includes an EOF token, it doesn't know what to do with it.
Most helpful comment
To put it another way: given a parse error, either the code can compile & run and we have a parser bug (there's a handful unhandled edge cases), or the code can't compile and won't run.
Alt+D,Enter (i.e. debug/compile) will have the VBE tell you where the problem is if it's a compile error, otherwise you can usually click the little 'x' icon to display the actual parser error; that's the toolwindow being referred to in the linked issue - it already exists :smiley: