[Cocci] Moving a function body to an other source code place with SmPL

[Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

Hello,

I am curious on how good the Coccinelle software can support a specific
source code transformation:
It would be occasionally nice if an implementation of a function could be
completely stored into a metavariable.
Is a statement list variable appropriate for this use case?

Can these data be moved to an other function (or macro definition)?

Regards,
Markus

[Cocci] Moving a function body to an other source code place with SmPL

[Julia Lawall]

On Mon, 14 May 2018, SF Markus Elfring wrote:

> Hello,
>
> I am curious on how good the Coccinelle software can support a specific
> source code transformation:
> It would be occasionally nice if an implementation of a function could be
> completely stored into a metavariable.
> Is a statement list variable appropriate for this use case?

Yes.

@@
identifier f;
statement list SS;
@@

f() {
  SS
}

A statement list metavariable should only be used as the body of a block
{}.  If it is not working at the top of a function, it should be possible
to fix that.

> Can these data be moved to an other function (or macro definition)?

Yes.  A statement list variable can be added anywhere a list of statements
is allowed, ie not necessarily as the complete body of a block.

julia

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

[Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

>> It would be occasionally nice if an implementation of a function could be
>> completely stored into a metavariable.
>> Is a statement list variable appropriate for this use case?
> 
> Yes.

Thanks for your acknowledgement that it should usually work.


I have noticed a moment ago that a blank line is not marked by the SmPL
asterisk operator (for a small source code example) so far.

Can such whitespace characters be also preserved there anyhow?


>> Can these data be moved to an other function (or macro definition)?
> 
> Yes.  A statement list variable can be added anywhere a list of statements
> is allowed, ie not necessarily as the complete body of a block.

How will the software behaviour evolve if I stumble on the message
?Fatal error: exception Coccinelle_modules.Common.Timeout? after passing
the parameter ?--timeout 123? for a change attempt with a C++ source file?
(Am I too impatient here?)

Regards,
Markus

[Cocci] Moving a function body to an other source code place with SmPL

[Julia Lawall]

On Mon, 14 May 2018, SF Markus Elfring wrote:

> >> It would be occasionally nice if an implementation of a function could be
> >> completely stored into a metavariable.
> >> Is a statement list variable appropriate for this use case?
> >
> > Yes.
>
> Thanks for your acknowledgement that it should usually work.
>
>
> I have noticed a moment ago that a blank line is not marked by the SmPL
> asterisk operator (for a small source code example) so far.
>
> Can such whitespace characters be also preserved there anyhow?

No.  Whitespace is never preserved in metavariables.

>
>
> >> Can these data be moved to an other function (or macro definition)?
> >
> > Yes.  A statement list variable can be added anywhere a list of statements
> > is allowed, ie not necessarily as the complete body of a block.
>
> How will the software behaviour evolve if I stumble on the message
> ?Fatal error: exception Coccinelle_modules.Common.Timeout? after passing
> the parameter ?--timeout 123? for a change attempt with a C++ source file?
> (Am I too impatient here?)

No evolution is planned.  I see no reason why matching the body of a
function should intrinsically cause a timeout.

julia

[Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

>> I have noticed a moment ago that a blank line is not marked by the SmPL
>> asterisk operator (for a small source code example) so far.
>>
>> Can such whitespace characters be also preserved there anyhow?
> 
> No.  Whitespace is never preserved in metavariables.

I guess that this aspect will trigger further software development consequences.

How should a function body be converted into a part of a macro then?


>> How will the software behaviour evolve if I stumble on the message
>> ?Fatal error: exception Coccinelle_modules.Common.Timeout? after passing
>> the parameter ?--timeout 123? for a change attempt with a C++ source file?
>> (Am I too impatient here?)
> 
> No evolution is planned.  I see no reason why matching the body of a
> function should intrinsically cause a timeout.

I am also unsure if the Coccinelle software can cope in an other time frame
with another example file I am experimenting a bit.

Regards,
Markus

[Cocci] Moving a function body to an other source code place with SmPL

[Julia Lawall]

On Mon, 14 May 2018, SF Markus Elfring wrote:

> >> I have noticed a moment ago that a blank line is not marked by the SmPL
> >> asterisk operator (for a small source code example) so far.
> >>
> >> Can such whitespace characters be also preserved there anyhow?
> >
> > No.  Whitespace is never preserved in metavariables.
>
> I guess that this aspect will trigger further software development consequences.
>
> How should a function body be converted into a part of a macro then?

If you want to do this, you might need to add \ at the ends of lines.  You
can do that in python or ocaml, treating the result as an identifier.

julia

>
>
> >> How will the software behaviour evolve if I stumble on the message
> >> ?Fatal error: exception Coccinelle_modules.Common.Timeout? after passing
> >> the parameter ?--timeout 123? for a change attempt with a C++ source file?
> >> (Am I too impatient here?)
> >
> > No evolution is planned.  I see no reason why matching the body of a
> > function should intrinsically cause a timeout.
>
> I am also unsure if the Coccinelle software can cope in an other time frame
> with another example file I am experimenting a bit.
>
> Regards,
> Markus
>

[Cocci] Checking the support for source code transformations with special characters

[Julia Lawall]

On Mon, 14 May 2018, SF Markus Elfring wrote:

> >> I have noticed a moment ago that a blank line is not marked by the SmPL
> >> asterisk operator (for a small source code example) so far.
> >>
> >> Can such whitespace characters be also preserved there anyhow?
> >
> > No.  Whitespace is never preserved in metavariables.
>
> How does such information fit to the following wording in the documentation?
> https://github.com/coccinelle/coccinelle/blob/848f85e256516330c06f5fd8dc782b854ed9aa03/docs/manual/introduction.tex#L4
>
> ?? automate repetitive source-to-source style-preserving program transformations ??

When Coccinelle adds code, it makes an effort to conform to the
indentation of the context in which the code is placed, not the context
from which the code was removed.  The goal is to preserve the stule of the
code as a whole.

julia

[Cocci] Checking data processing for statement lists

[Julia Lawall]

On Tue, 15 May 2018, SF Markus Elfring wrote:

> >> How will the software behaviour evolve if I stumble on the message
> >> ?Fatal error: exception Coccinelle_modules.Common.Timeout? after passing
> >> the parameter ?--timeout 123? for a change attempt with a C++ source file?
> >> (Am I too impatient here?)
> >
> > No evolution is planned.
>
> I suggest to reconsider such a view.
>
> It is possible to perform some data processing with the help of the semantic
> patch language also on C++ source files in an acceptable time frame.
>
> Example:
> https://trac.cppcheck.net/ticket/8571
>
>
> > I see no reason why matching the body of a function should intrinsically
> > cause a timeout.
>
> I accidentally observed that the software situation can be changed
> in a dramatic way if a metavariable of the type ?statement list? is involved.
> Can the run time characteristics be considerably improved?

I don't have either semantic patch or the test data.  Perhaps you sent
them but without mentioning it in the message, so I didn't see it.

There is nothing about the processing of C++ that should be particularly
time consuming.

julia