Ballerina-lang: Unexpected parser recovery for missing resource-accessor

[rdhananjaya]

Description:

public type ServiceOne service object {
    resource string message;
    resource function get detail/name/otherBit() returns string;
};

In the above code, if we don't have the get accessor, the parser recover this by taking detail as the accessor and [missing]/name/otherBit as the relative resource path.

Steps to reproduce:

Affected Versions:
service-change branch

OS, DB, other environment details and versions:

Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

[lochana-chathura]

Correct resource-accessor-declaration:

resource function get detail/name/otherBit() returns string;

Let's consider following two erroneous scenarios.

1. missing accessor-name(eg. get)

resource function detail/name/otherBit() returns string;

1. missing initial identifier in the relative resource path

resource function get /name/otherBit() returns string;

If we ignore the space syntactically they both have the same grammar.
Current way of parsing for both cases is,

• parse the identifier after function as accessor-name
• go to recovery with slash token. Since we give priority to insert, solution is to insert missing identifier.

@SupunS Do we need to distinguish above two scenarios in the parser?

[SupunS]

What does the spec say about the spaces in the middle of the resource-path?
Is something like afoo / bar / a valid one? If its not valid, then probably we can try to distinguish (as an improvement). But if thats valid, then we can't distinguish.

BTW, theres a third scenario as well:

resource function foo () returns string;

This I think we can't distinguish anyway.

[rdhananjaya]

resource function is still not incorperated to the spec and in proposal stage, the grammer specified in the proposal is:

resource-accessor-defn :=
  metadata "resource" "function" accessor-name resource-name
   function-signature method-defn-body
accessor-name := identifier
resource-name := identifier

Latter in the proposal this resource-name bit is identified as a resource path

relative-resource-path := "." | (identifier ("/" identifier)*)

Since this is a network path I don't think space character will be allowed in it.

@hasithaa please add if I missed anything.

[SupunS]

If we go with the grammar relative-resource-path := "." | (identifier ("/" identifier)*), then whitespaces are actually allowed within the resource path at the syntax level...

[rdhananjaya]

@SupunS not sure how space charactors are allowed in that grammer, we don't allowe space char within identifer right?

[SupunS]

It is mentioned under the notation section: https://ballerina.io/ballerina-spec/spec.html#notation

The rhs of a symbol that starts with a lower-case letter implicitly allows white space and comments, as defined by the production TokenWhiteSpace, between the terminals and nonterminals that it references.

Simpler version is: If the production name start with an upper-case letter (Camel case), then there is no WS between the tokens in the production. Otherwise WS is allowed between the tokens.

[rdhananjaya]

Ack. Thank you, didn't know about that bit.

Closing this issue as it's not possible to distinguish between missing accessor-name and an invalid or missing resource path.