[Cocci] Checking the parsing for a nested SmPL disjunction

[Cocci] Checking the parsing for a nested SmPL disjunction

[Markus Elfring]

Hello,

I have tried another small script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00131-g675b9670”).

@display@
type t1, t2;
expression action;
identifier resource, y;
statement is, es;
@@
 t1* resource;
 <+... when any
(t2 y = <+...
(       sizeof(*(resource))
|
*       *(resource)
)       ...+>
|
*action(..., resource, ...)
)
 ...+>


elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_problematic_disjunction-20200626.cocci
…
minus: parse error:
  File "show_problematic_disjunction-20200626.cocci", line 14, column 0, charpos = 196
  around = '|',
  whole content = |


May I expect that such SmPL disjunctions should also work?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]



On Fri, 26 Jun 2020, Markus Elfring wrote:

> Hello,
>
> I have tried another small script variant out for the semantic patch language
> (according to the software combination “Coccinelle 1.0.8-00131-g675b9670”).
>
> @display@
> type t1, t2;
> expression action;
> identifier resource, y;
> statement is, es;
> @@
>  t1* resource;
>  <+... when any
> (t2 y = <+...
> (       sizeof(*(resource))
> |
> *       *(resource)
> )       ...+>

You are missing a ; here.

julia


> |
> *action(..., resource, ...)
> )
>  ...+>
>
>
> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_problematic_disjunction-20200626.cocci
> …
> minus: parse error:
>   File "show_problematic_disjunction-20200626.cocci", line 14, column 0, charpos = 196
>   around = '|',
>   whole content = |
>
>
> May I expect that such SmPL disjunctions should also work?
>
> Regards,
> Markus
> _______________________________________________
> Cocci mailing list
> Cocci@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Markus Elfring]

>>  <+... when any
>> (t2 y = <+...
>> (       sizeof(*(resource))
>> |
>> *       *(resource)
>> )       ...+>
>
> You are missing a ; here.

I assumed that I may omit the semicolon in such a SmPL code.
Can the specification of a SmPL nest construct ever be sufficient here?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Julia Lawall]

On Fri, 26 Jun 2020, Markus Elfring wrote:

> >>  <+... when any
> >> (t2 y = <+...
> >> (       sizeof(*(resource))
> >> |
> >> *       *(resource)
> >> )       ...+>
> >
> > You are missing a ; here.
>
> I assumed that I may omit the semicolon in such a SmPL code.
> Can the specification of a SmPL nest construct ever be sufficient here?

No.  <+... ...+> matches a subtree of an AST.  For a variable
initialization, there is no subtree of the AST that includes both the
right side of an = and the ;.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Markus Elfring]

>> I assumed that I may omit the semicolon in such a SmPL code.
>> Can the specification of a SmPL nest construct ever be sufficient here?
>
> No.  <+... ...+> matches a subtree of an AST.  For a variable
> initialization, there is no subtree of the AST that includes both the
> right side of an = and the ;.

Can the abstract syntax tree be adjusted accordingly?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Julia Lawall]

On Fri, 26 Jun 2020, Markus Elfring wrote:

> >> I assumed that I may omit the semicolon in such a SmPL code.
> >> Can the specification of a SmPL nest construct ever be sufficient here?
> >
> > No.  <+... ...+> matches a subtree of an AST.  For a variable
> > initialization, there is no subtree of the AST that includes both the
> > right side of an = and the ;.
>
> Can the abstract syntax tree be adjusted accordingly?

No.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Markus Elfring]

>>>> I assumed that I may omit the semicolon in such a SmPL code.
>>>> Can the specification of a SmPL nest construct ever be sufficient here?
>>>
>>> No.  <+... ...+> matches a subtree of an AST.  For a variable
>>> initialization, there is no subtree of the AST that includes both the
>>> right side of an = and the ;.
>>
>> Can the abstract syntax tree be adjusted accordingly?
>
> No.

Can such a rejection mean that software development efforts look undesirable
(while adjustments for the data model would eventually be possible)?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the parsing for a nested SmPL disjunction

[Julia Lawall]

On Fri, 26 Jun 2020, Markus Elfring wrote:

> >>>> I assumed that I may omit the semicolon in such a SmPL code.
> >>>> Can the specification of a SmPL nest construct ever be sufficient here?
> >>>
> >>> No.  <+... ...+> matches a subtree of an AST.  For a variable
> >>> initialization, there is no subtree of the AST that includes both the
> >>> right side of an = and the ;.
> >>
> >> Can the abstract syntax tree be adjusted accordingly?
> >
> > No.
>
> Can such a rejection mean that software development efforts look undesirable
> (while adjustments for the data model would eventually be possible)?

No, it means that it makes no sense and it is not going to happen.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci