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.

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

return statement parsing needs to be more restrictive #979

Open
nofun97 opened this issue Jul 30, 2020 · 1 comment
Open

return statement parsing needs to be more restrictive #979

nofun97 opened this issue Jul 30, 2020 · 1 comment
Labels
enhancement P1 Medium priority

Comments

@nofun97
Copy link
Member

nofun97 commented Jul 30, 2020

Purpose

To get a better resulting protobuf structure from return statements.

Problem

Currently, the grammar for return statement is

ret_stmt        : RETURN TEXT;

which basically just parses anything next to the token return. The resulting json of the return statement is

{
       "ret": {
        "payload": "Anything next to the word return"
       }
}

This makes it difficult to extract any information from the return statement. This also removes the ability to add modifiers which is allowed in the sysl grammar.

statements: ( ...
                | ret_stmt
                ...
            )
            attribs_or_modifiers?
            ;

Suggested approaches

Allow a more restrictive grammar to return statements. Something like the following:

status_code: [2-5][0-9][0-9];
ret_stmt: RETURN (OK | ERROR | status_code) LESS_COLON TEXT;

The token TEXT above needs to capture everything and stops until a square bracket to make way for attribs_or_modifiers rule.

The structure for return statement also needs to be improved.

type Return struct {
	state         protoimpl.MessageState
	sizeCache     protoimpl.SizeCache
	unknownFields protoimpl.UnknownFields

	Payload string `protobuf:"bytes,1,opt,name=payload,proto3" json:"payload,omitempty"`
}

it needs to capture the type of return statement (ok, error, and status_code) and the payload (what is being returned).

@orlade-anz orlade-anz added P0 Highest priority: important or urgent P1 Medium priority and removed P0 Highest priority: important or urgent labels Jul 30, 2020
@orlade-anz
Copy link
Collaborator

Not P0 since we can work around this in post-processing for the time being.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement P1 Medium priority
Projects
None yet
Development

No branches or pull requests

2 participants