-
Notifications
You must be signed in to change notification settings - Fork 53
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
Support literal numbers with explicit plus sign (#633) #640
Support literal numbers with explicit plus sign (#633) #640
Conversation
Fixes issue #633 where previously the compiler would yield an error if it encountered a number with an explicit plus sign, i.e. the following was previously not supported but is now ``` foo : DINT := +2147483647; ```
Codecov ReportBase: 93.76% // Head: 93.76% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #640 +/- ##
=======================================
Coverage 93.76% 93.76%
=======================================
Files 46 46
Lines 17604 17620 +16
=======================================
+ Hits 16506 16522 +16
Misses 1098 1098
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @volsa, thx for the PR!
the check-style-step of the build failed, you can fix the formatting via: cargo fmt
PROGRAM exp | ||
x : DINT := 1; | ||
y : DINT := +1; | ||
END_PROGRAM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this ST-code is not 100% correct. it should maybe look like this:
PROGRAM exp
VAR
x : INT;
END_VAR
x := 1;
x := +1;
END_PROGRAM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, would the following ST-code also be wrong because it's missing a VAR
block?
PROGRAM exp
x := NULL;
END_PROGRAM
(taken from the assignment_to_null()
test)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, would the following ST-code also be wrong because it's missing a
VAR
block?PROGRAM exp x := NULL; END_PROGRAM(taken from the
assignment_to_null()
test)
so technically this works, if x is declared somewhere as a global variable. When we do parse tests, we often dont have semantically correct cases: (e.g. we dont care if x would resolve to something meaningful or not).
your sourcode mixed a statement and a declaration, you cannot have declarations outside of VAR-blocks.
I was really surprised that the parser actually returned something 😄 . but if you look at your assignment, the parser created something very strange:
Assignment{ left: "DINT", right: "1" }
so the parser thought that DINT is an identifer to a variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense, thanks for clarifying.
I did some experiments and it looks like this code only covers behavior for literals. Can we also fix & test the behavior for reference? like: ? rusty/src/parser/expressions_parser.rs Lines 171 to 178 in 44bad56
|
Done! Fingers crossed the style-checker doesn't throw an error :P |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice, thx! 👍
Hi, #633 looked like a beginner friendly issue so I thought I'd give it a shot; the PR should be hopefully OK :)