Closed engineerjoe440 closed 1 year ago
Merging #56 (043f20e) into master (c6e0e18) will increase coverage by
0.3%
. The diff coverage is100.0%
.
OK, I've confirmed this parses all of our codebase at least as well as the previous commit. Only a single unexpected failure which (if I recall correctly - correct me if I'm wrong!) goes through a separate grammar rule than what you've introduced here:
(UnexpectedCharacters) No terminal matches '#' in the current parser context, at line 43 col 25
i_TypeCode := 10#1010);
^
This is worthy of a separate issue + PR to fix, if so
OK, I've confirmed this parses all of our codebase at least as well as the previous commit. Only a single unexpected failure which (if I recall correctly - correct me if I'm wrong!) goes through a separate grammar rule than what you've introduced here:
(UnexpectedCharacters) No terminal matches '#' in the current parser context, at line 43 col 25 i_TypeCode := 10#1010); ^
This is worthy of a separate issue + PR to fix, if so
I was hoping to have reviewed this more closely today, but haven't had a chance to... yet. This seems like a new issue to me. Was this not appearing with master-branch blark
? Only with these changes? I'd like to better wrap my head around that, and potentially get a fix, anyway.
Sorry, that was poorly phrased on my part!
blark master and this PR fail in the same way parsing that source code file. It was closely related in grammar rules to this PR so it gave me pause. Looking at its tree (avoiding the base-specifying 10#
part that's throwing it off) gives:
structure_initialization
structure_element_initialization
i_DevName
constant
string_literal 'MPA'
structure_element_initialization
i_Desc
constant
string_literal 'Fault occurs when the device is moving'
structure_element_initialization
i_TypeCode
constant
And... it turns out we don't have a rule for explicit base 10 integer literals. D'oh! https://github.com/klauer/blark/blob/043f20ed36c25ac793886181b0a5c0232f218930/blark/iec.lark#L61-L65
Will TwinCAT accept any base or just binary/hex/octal/decimal, I wonder... Hmm...
In any case, this PR is great! Thanks again. I'm going to merge and make an issue for the above.
Aha!!!! I see your point!!! Thank you so much, @klauer! :smile:
Related Issues
44
Changes
VAR_INPUT
andVAR_IN_OUT
).Closing Thoughts
Hopefully with these additions, some of the "in-the-wild" code we've come across will get patched up and parse as we expect. :smile: