grammars-v4
grammars-v4 copied to clipboard
Update vba.g4
bug fix for line labels, allowing line labels to have white space after the colon
I just submitted a VBA pull request as well. #3881
Let me know if you have any advice on what to do or not to do regarding ANTLR and Linting VBA.
The TypeScript target environment somehow changed. TypeScript on my machine now also doesn't work.
I have to change the templates for TypeScript. See Issue #3882 . Once done, you can fast forward/rebase to include the change and try again. My fix is in https://github.com/antlr/grammars-v4/pull/3883.
Please add/extend an example that covers suggested changes to the examples subdirecotry.
The sub directory should already have line numbers i added last patch of mine, this one just fixes them since before if your line numbers had white space after them they didnt parse correctly.
@Xenios91 would it be worthwhile adding some whitespace to one of the line numbered lines, to demonstrate that that case fails under the existing grammar, but passes under the new grammar?
@KvanTTT good to merge this?
No, I suggest adding a test data in the way @Beakerboy suggested.
@Xenios91 The VBA editor that ships with excel automatically strips trailing whitespace out of a line label. If the line label is on the same line as a statement, there can be whitespace between them. Should the whitespace be considered part of the label, or as a separator between different contexts?
Using underscore for trailing whitespace:
Function Foo(x)
If x > 1 GoTo line2
'cannot produce this in the IDE
line1:__
Foo = 5
GoTo final
'This is valid
line2: Foo = 1
final:
End Function
@Xenios91 The VBA editor that ships with excel automatically strips trailing whitespace out of a line label. If the line label is on the same line as a statement, there can be whitespace between them. Should the whitespace be considered part of the label, or as a separator between different contexts?
Using underscore for trailing whitespace:
Function Foo(x) If x > 1 GoTo line2 'cannot produce this in the IDE line1:__ Foo = 5 GoTo final 'This is valid line2: Foo = 1 final: End Function
Right, I have just come across documents in the wild that it fails to parse them correctly when there is this white space, so while it should be removed, it seems like it is not. I speculate this may be due to a document being generated by something like apache poi or another library where the vba formatter doesnt clean it up. Id say for now maybe just an optional character for line labels, as making it a separator may impact other parts of the grammar. The more I think about it, i believe a lot of the parsing errors I am seeing are from automated techniques to generate documents where that VBA cleanup doesnt occur.
being generated by something like apache poi …
I had not heard of Apache POI, so I looked it up. I’ve been working on my own OLE file writer for quite a while. I wish I knew this was out there. Thanks!
being generated by something like apache poi …
I had not heard of Apache POI, so I looked it up. I’ve been working on my own OLE file writer for quite a while. I wish I knew this was out there. Thanks!
oh yeah its pretty nice!
test added
does the block section need to be changed to
block
: block-element+
;
block-element
: lineLabel endOfLine
| lineLabel? blockStmt (endOfStatement blockStmt)* endOfStatement
and then remove lineLabel from blockStmt. I feel this should ensure that the line label can only occur without leading whitespace, and also that is properly identified when it is alone on a line and when it is followed with statements.
can line numbers also appear on the lame line as other statements. The grammar currently states that there must be a line break at the end. Either way, lineNumber would probably be handled similarly.
One issue I see…how is the parser supposed to know that when it sees:
foo: x=1
that it is a line labeled ‘foo’ versus a call to the foo subroutine, followed by a let statement?