Discussion:
[Cocci] Avoiding code duplication for SmPL constraints
SF Markus Elfring
2018-02-17 13:34:49 UTC
Permalink
Hello,

Constraints can be specified for metavariables of the semantic patch language.
I noticed that they can trigger software maintenance challenges
when bigger specifications are repeated in some SmPL rules.
Now I am looking again for further possibilities to avoid corresponding
code duplication.

* Scripted constraints might be a design option.
Unfortunately, I find the documentation for this functionality still incomplete.

* I imagine that it would nice if constraints could be set by programming script
rules at a single place.

Regards,
Markus
Julia Lawall
2018-02-17 13:39:02 UTC
Permalink
Post by SF Markus Elfring
Hello,
Constraints can be specified for metavariables of the semantic patch language.
I noticed that they can trigger software maintenance challenges
when bigger specifications are repeated in some SmPL rules.
Now I am looking again for further possibilities to avoid corresponding
code duplication.
* Scripted constraints might be a design option.
Unfortunately, I find the documentation for this functionality still incomplete.
What information do you find to be lacking?
Post by SF Markus Elfring
* I imagine that it would nice if constraints could be set by programming script
rules at a single place.
The simplest thing to do is to define a function in the initialize part of
the semantic patch, and then call that function in the constraints as
needed.

julia
Julia Lawall
2018-02-17 14:11:58 UTC
Permalink
Post by Julia Lawall
Post by SF Markus Elfring
Now I am looking again for further possibilities to avoid corresponding
code duplication.
* Scripted constraints might be a design option.
Unfortunately, I find the documentation for this functionality still incomplete.
What information do you find to be lacking?
I would appreciate if the place for the desired predicate will be better explained.
May they refer to a predefined function?
When you write eg

identifier x : script:python(...) { ... };

or

identifier x : script:ocaml(...) { ... };

Between the { ... } you can put any code that you could put in a python or
ocaml script, respectively.

julia
Julia Lawall
2018-02-17 14:34:43 UTC
Permalink
Post by Julia Lawall
I would appreciate if the place for the desired predicate will be better explained.
May they refer to a predefined function?
When you write eg
identifier x : script:python(...) { ... };
or
identifier x : script:ocaml(...) { ... };
Between the { ... } you can put any code that you could put in a python or
ocaml script, respectively.
Which parameters should be passed to the selected function?
You can always pass the declared metavariable. You can put a
comma-separated list of inherited metavariables (r.a, r.b, ...) between
the parentheses, and then use a, b, etc in the script code. If there are
no disjunctions in the rule and if the declared metavariable is no
seprated by ... from a metavariable previously declared in the same rule,
then the latter variable can be included in the () as well, with no rule
name, and then used in the script code.

julia
SF Markus Elfring
2018-02-17 14:54:16 UTC
Permalink
Post by Julia Lawall
Which parameters should be passed to the selected function?
You can always pass the declared metavariable.
I have got special imaginations for convenient parameter passing
in such an use case.
Post by Julia Lawall
You can put a comma-separated list of inherited metavariables
Do you suggest that a dependency on metavariable inheritance is required?
Post by Julia Lawall
(r.a, r.b, ...) between the parentheses, and then use a, b, etc in the script code.
I would appreciate if the needed data would be directly available for
the predicate function (without repeating variable names).
Post by Julia Lawall
If there are no disjunctions in the rule and if the declared metavariable
is no seprated by ... from a metavariable previously declared in the same rule,
then the latter variable can be included in the () as well, with no rule
name, and then used in the script code.
I find this condition hard to understand at the moment.

Regards,
Markus

Loading...