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

'var_declarations' with variable containing 'VAR_ATTRIB' in name at start parses incorrectly #106

Open
Caius-Bonus opened this issue Dec 16, 2024 · 1 comment · May be fixed by #107
Open

'var_declarations' with variable containing 'VAR_ATTRIB' in name at start parses incorrectly #106

Caius-Bonus opened this issue Dec 16, 2024 · 1 comment · May be fixed by #107

Comments

@Caius-Bonus
Copy link

Example:

PROGRAM Test
VAR
    RetainInt: INT;
END_VAR
END_PROGRAM

This parses as variable called "Int" with variable attribute "Retain" and type "INT".
It is supposed to parse as variable called "RetainInt" with no variable attributes and type "INT".

I don't have any experience with lark, but I think a simple solution would be to guard against this with a change in iec.lark: variable_attributes: /(VAR_ATTRIB(!?\w))/+. to prevent it being followed by other letters (should also immediately guard against multiple attributes being written without spaces).
klauer added a commit that referenced this issue Dec 17, 2024
@klauer
FIX: proof-of-concept for fixing #106
1b740a0
@klauer
Copy link
Owner

klauer commented Dec 17, 2024

Thanks for the bug report!

You uncovered somewhat of a larger/systematic issue with how blark's grammar is much too relaxed with respect to real whitespace grammar rules.

This specific issue could potentially be fixed on a per-token basis (along the lines of this change) by adding in lookbehind and lookahead regular expression markers that expect there to be whitespace before and after the token. I'm not 100% sure if this is the best way to go about it, though.

If it is, the grammar will have a fair amount of updates needed as there are a number of other similar scenarios - where whitespace happens to be an important delimiter.

@klauer klauer linked a pull request Dec 18, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

FIX: a sweeping fix for keyword word boundary handling klauer/blark
2 participants
@klauer @Caius-Bonus