-
Notifications
You must be signed in to change notification settings - Fork 2
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
Int relational operators #76
Conversation
=> setConstant(Name, implicitCast(V, T)) | ||
=> setConstant(Name, implicitCast(V, T)) | ||
|
||
// rule |
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.
Maybe remove the comment?
@@ -10,7 +10,11 @@ module RUST-CONSTANTS | |||
|
|||
rule | |||
(const Name:Identifier : T:Type = V:Value;):ConstantItem:KItem | |||
=> setConstant(Name, implicitCast(V, T)) | |||
=> setConstant(Name, implicitCast(V, T)) |
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.
Why is there a diff for this line?
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.
I'm honestly not sure. I think it may be a change of tabs for spaces, perhaps. Will try to figure it out.
@@ -23,6 +27,8 @@ module RUST-CONSTANTS | |||
<constant-value> V </constant-value> | |||
</constant> | |||
... | |||
</constants> | |||
</constants> |
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.
Why is there a diff for this line?
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.
I had implemented a rule below and added some empty lines before. It seems like leaving a blank line below triggered this.
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.
I checked this again, and you may have added spaces at the end of the line.
rust-semantics/rust-common-syntax.md
Outdated
@@ -257,8 +257,7 @@ https://doc.rust-lang.org/reference/items/extern-crates.html | |||
| ByteLiteral | ByteStringLiteral | RawByteStringLiteral | |||
| CStringLiteral | RawCStringLiteral | |||
| IntegerLiteral | FloatLiteral | |||
| "true" | "false" | |||
|
|||
|
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.
Why is there a diff for this line? It should be identical with the empty line in the original file.
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.
It was meaningless spaces. I've just removed it.
@@ -257,8 +257,7 @@ https://doc.rust-lang.org/reference/items/extern-crates.html | |||
| ByteLiteral | ByteStringLiteral | RawByteStringLiteral | |||
| CStringLiteral | RawCStringLiteral | |||
| IntegerLiteral | FloatLiteral | |||
| "true" | "false" |
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.
Are you sure these aren't needed here? Would this grammar still parse a .rs file containing true/false? Even if the file is still parsable (e.g. it may identify true/false as identifiers), why is it a good idea to remove these?
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.
My motivation for removing them was to primarily eliminate parsing ambiguity in the execution module. Having a syntax element named true
of type Expression
was causing issues on, for instance, the check_eq true
in the testing files, as it didn't recognize if this true
was an Expression
or a Bool
.
Keeping Bool
as a part of Values
is also advantageous for us as we do not need to write new rules for assignments of constants and variables, and also makes it easier for us to reuse the return of the relational operations of MInt
s.
Finally, please, correct me if I'm wrong, but my understanding is that an Expression
can also be constituted by a single Value
. So having Booleans as a part of Values
allows us to have effectively the same syntax of adding true
and false
to the Expression
definition, with the advantage of having the boolean operations implemented in the BOOL module being supported here.
@@ -17,6 +17,7 @@ module RUST-EXPRESSION-INTEGER-LITERALS | |||
syntax String ::= IntegerLiteralToString(IntegerLiteral) [function, total, hook(STRING.token2string)] | |||
|
|||
rule I:IntegerLiteral => wrapPtrValueOrError(null, parseInteger(I)) | |||
rule B:Bool:LiteralExpression => wrapPtrValueOrError(null, B:Bool:Value) |
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 works, but you could also write ptrValue(null, B:Bool:Value)
directly.
This pull request implements relational operations for integers in our rust-lite semantics.