Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support literal numbers with explicit plus sign (#633) #640

Merged
merged 4 commits into from
Nov 10, 2022
Merged

Support literal numbers with explicit plus sign (#633) #640

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c26bdd4
fix: Support literal numbers with explicit plus sign (#633)
volsa Nov 8, 2022
64d752e
Remove `println!`
volsa Nov 8, 2022
df46a75
Implement PR feedback
volsa Nov 9, 2022
87b6040
Merge branch 'master' into 633-literal-numbers-with-plus-sign
riederm Nov 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 22 additions & 16 deletions src/parser/expressions_parser.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,22 +255,27 @@ fn parse_leaf_expression(lexer: &mut ParseSession) -> AstStatement {
None
};

let literal_parse_result = if lexer.allow(&OperatorMinus) {
//so we've seen a Minus '-', this has to be a number
match lexer.token {
LiteralInteger => parse_literal_number(lexer, true),
LiteralIntegerBin => parse_literal_number_with_modifier(lexer, 2, true),
LiteralIntegerOct => parse_literal_number_with_modifier(lexer, 8, true),
LiteralIntegerHex => parse_literal_number_with_modifier(lexer, 16, true),
_ => Err(Diagnostic::unexpected_token_found(
"Numeric Literal",
lexer.slice(),
lexer.location(),
)),
let literal_parse_result = match lexer.token {
// Check if we're dealing with a number that has an explicit '+' or '-' sign...
OperatorPlus | OperatorMinus => {
let is_negative = lexer.token == OperatorMinus;
lexer.advance();

match lexer.token {
LiteralInteger => parse_literal_number(lexer, is_negative),
LiteralIntegerBin => parse_literal_number_with_modifier(lexer, 2, is_negative),
LiteralIntegerOct => parse_literal_number_with_modifier(lexer, 8, is_negative),
LiteralIntegerHex => parse_literal_number_with_modifier(lexer, 16, is_negative),
_ => Err(Diagnostic::unexpected_token_found(
"Numeric Literal",
lexer.slice(),
lexer.location(),
)),
}
}
} else {
// no minus ... so this may be anything
match lexer.token {

// ...and if not then this token may be anything
_ => match lexer.token {
Identifier => parse_qualified_reference(lexer),
LiteralInteger => parse_literal_number(lexer, false),
LiteralIntegerBin => parse_literal_number_with_modifier(lexer, 2, false),
Expand Down Expand Up @@ -308,8 +313,9 @@ fn parse_leaf_expression(lexer: &mut ParseSession) -> AstStatement {
))
}
}
}
},
};

let literal_parse_result = literal_parse_result.and_then(|statement| {
if let Some((cast, location)) = literal_cast {
//check if there is something between the literal-type and the literal itself
Expand Down
30 changes: 30 additions & 0 deletions src/parser/tests/expressions_parser_tests.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1513,6 +1513,36 @@ fn assignment_to_null() {
assert_eq!(ast_string, expected_ast);
}

#[test]
fn assignment_to_number_with_implicit_and_explicit_plus_sign() {
let src = "
PROGRAM exp
x : DINT := 1;
y : DINT := +1;
END_PROGRAM
Copy link
Collaborator

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

Copy link
Member Author

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)

Copy link
Collaborator

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.

Copy link
Member Author

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.

";

let result = parse(src).0;
let statements = &result.implementations[0].statements;

let ast_string_implicit = format!("{:#?}", statements[1]);
let ast_string_explicit = format!("{:#?}", statements[3]);

let expected_ast = r#"Assignment {
left: Reference {
name: "DINT",
},
right: LiteralInteger {
value: 1,
},
}"#;

// Both the implicit and explicit assignment should yield the same output
// which in turn should be `expected_ast`
assert_eq!(ast_string_implicit, ast_string_explicit);
assert_eq!(ast_string_implicit, expected_ast);
}

#[test]
fn pointer_address_test() {
let src = "
Expand Down