From: Markus Elfring <Markus.Elfring@web.de>
To: Jacob Keller <jacob.e.keller@intel.com>, cocci@inria.fr
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [cocci] behavior change in semantic patches since c36b51ffc889 …
Date: Sat, 8 Mar 2025 09:39:06 +0100 [thread overview]
Message-ID: <26d75b7d-e9e1-4037-8f25-b8d93bd0950b@web.de> (raw)
In-Reply-To: <90c4769b-0247-492f-a137-fec1c970eaf5@intel.com>
> I tried this out and it does seem to fix the white spacing for our
> particular cases.
Thanks for such positive feedback.
Will your development interests grow also for further SmPL code variations?
> From here, I just repeated the process until git bisect told me which
> commit had the breaking change.
How many iterations did you need to try out here?
> There were a couple gotchas where the checked out commit didn't compile
> but I managed to figure out which changes were needed and manually
> pulled those in each time.
Do you see chances to improve such a process anyhow?
> I think the white spacing is a hard problem, because each project will
> have their own style and rules. For many cases, the expectation is that
> a human would manually cleanup the results.
Various contributors are struggling with desirable adjustments also
in affected areas.
> In my case, we run this as part of our build process to clean up code
> automatically, and don't commit the results.
Thanks for another bit of background information.
> I suspect this is counter
> to the original intention.
It seems that you got into a position where you may stress the importance
of safe data processing automation.
> One option would be to run a style formatting
> tool after transforms, to allow a tool dedicated to code formatting vs
> trying to make spatch and coccinelle do everything these can do.
Are you looking for ways to avoid extra efforts for code reformatting?
> I do think improvements in the way you can specify spacing would be
> useful but may complicate the already difficult syntax of semantic patches.
Adhering to code style requirements can be challenging.
Regards,
Markus
next prev parent reply other threads:[~2025-03-08 8:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 0:43 [cocci] behavior change in semantic patches since c36b51ffc889 ("don't drop down on single statement") Jacob Keller
2025-03-07 0:55 ` Julia Lawall
2025-03-07 20:24 ` Jacob Keller
2025-03-07 10:47 ` [cocci] behavior change in semantic patches since c36b51ffc889 … Markus Elfring
2025-03-07 20:53 ` Jacob Keller
2025-03-07 22:47 ` Jacob Keller
2025-03-08 9:07 ` Markus Elfring
2025-03-10 18:34 ` Jacob Keller
2025-03-11 9:10 ` Markus Elfring
2025-03-08 8:39 ` Markus Elfring [this message]
2025-03-10 18:27 ` Jacob Keller
2025-03-11 9:26 ` Przemek Kitszel
2025-03-08 9:45 ` [cocci] Evolution of transformation processes? Markus Elfring
2025-03-10 18:23 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26d75b7d-e9e1-4037-8f25-b8d93bd0950b@web.de \
--to=markus.elfring@web.de \
--cc=cocci@inria.fr \
--cc=jacob.e.keller@intel.com \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.