New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating-point literals with comma decimal separator gives parsing error #4983
Comments
I took the liberty to reformat this a bit and change the screenshotted code into text. This allows devs to just copy-paste it into their local environment for verification :) |
As far as I can tell, this issue arises from how the lexer defines floating point literals: Rubberduck/Rubberduck.Parsing/Grammar/VBALexer.g4 Lines 255 to 261 in 99e9094
Note the explicit use of Considering how "early in the parsing pipeline" this is, any changes to the rule are potentially catastrophic. - | DECIMALLITERAL '.' DECIMALLITERAL? EXPONENT?
- | '.' DECIMALLITERAL EXPONENT?;
+ | DECIMALLITERAL DECIMAL_SEPARATOR DECIMALLITERAL? EXPONENT?
+ | DECIMAL_SEPARATOR DECIMALLITERAL EXPONENT?;
+ fragment DECIMAL_SEPARATOR : [,.]; This would open us up to misparsing different numerical arguments in VBA code, though.
We need to get an That is obviously incorrect. After all, this is two interger literal arguments. In my personal opinion a change like this is highly dangerous. |
I agree, we can't just parse a decimal separator interchangeably as a comma or a dot. I think we might need a separate |
Shouldn't this |
That would be a pretty-printed version; however, AIUI, |
The code you read in the VBE in a validated line of code isn't the code you typed in the editor: it's a translation of the compiled instruction - that's why/how the VBE "prettifies" code and "autocorrects" certain constructs; that space is an artifact of this translation, it's nowhere in the language specifications; (see argument list) - having parser logic depend on how the VBE prettifies user code is something we need to avoid whenever possible. |
I understand. Thanks. |
Since this error appears in the form section, which we do not evaluate anyway (We just have to parse it to get to the actual module.), I would like to suggest to just patch up the parser rule for the forms part with an additional alternative |
Rubberduck Version:
Description
There was already a bug with this problem fixed in #1178.
My problem is that our source code is totally mixed with
FontSize = 8,25
and
FontSize = 8.25
also in the same files. VB doesn't have any problems with it, but RD gives many parsing errors.
To Reproduce
Create a form with 2 TextBoxes, manually edit the file and change FontSize.
I think that happened a long time ago with different Windows and VB6 language
versions.
The code looks like this:
Expected behavior
RD should parse both values correctly
Logfile
The text was updated successfully, but these errors were encountered: