From: Marc-André Lureau <marcandre.lureau@redhat.com>
Make the resulting code even prettier, if possible.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
scripts/qapi/gen.py | 15 ++++++++++++++-
scripts/qapi/introspect.py | 2 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/scripts/qapi/gen.py b/scripts/qapi/gen.py
index b5a8d03e8e..c0ec9aa412 100644
--- a/scripts/qapi/gen.py
+++ b/scripts/qapi/gen.py
@@ -14,6 +14,7 @@
from contextlib import contextmanager
import os
import re
+import subprocess
from typing import (
Dict,
Iterator,
@@ -133,6 +134,7 @@ def build_params(arg_type: Optional[QAPISchemaObjectType],
class QAPIGenCCode(QAPIGen):
def __init__(self, fname: str):
super().__init__(fname)
+ self.skip_format: bool = False
self._start_if: Optional[Tuple[QAPISchemaIfCond, str, str]] = None
def start_if(self, ifcond: QAPISchemaIfCond) -> None:
@@ -149,7 +151,18 @@ def end_if(self) -> None:
def get_content(self) -> str:
assert self._start_if is None
- return super().get_content()
+
+ text = super().get_content()
+ if not self.skip_format:
+ try:
+ text = subprocess.run(["clang-format"],
+ input=text,
+ text=True,
+ capture_output=True,
+ check=True).stdout
+ except FileNotFoundError:
+ pass
+ return text
class QAPIGenC(QAPIGenCCode):
diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py
index 67c7d89aae..1a8cac37ef 100644
--- a/scripts/qapi/introspect.py
+++ b/scripts/qapi/introspect.py
@@ -174,6 +174,8 @@ def __init__(self, prefix: str, unmask: bool):
super().__init__(
prefix, 'qapi-introspect',
' * QAPI/QMP schema introspection', __doc__)
+ # for some reasons, the generated code is making clang-format go crazy
+ self._genc.skip_format = True
self._unmask = unmask
self._schema: Optional[QAPISchema] = None
self._trees: List[Annotated[SchemaInfo]] = []
--
2.39.2
Does anything in the series depend on this patch?
Hi On Mon, Mar 6, 2023 at 8:03 PM Markus Armbruster <armbru@redhat.com> wrote: > > Does anything in the series depend on this patch? > Indeed, it's no longer directly relevant for this series. It's a left-over from various iterations. Nevertheless, feedback welcome. -- Marc-André Lureau
On Mon, 6 Mar 2023 at 12:33, <marcandre.lureau@redhat.com> wrote: > > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > Make the resulting code even prettier, if possible. This seems to be a bit short on rationale. This is generated code, so in general nobody is going to be reading it, and running clang-format on it every time we generate code feels like it would be a bit of a waste of cycles... thanks -- PMM
Hi On Mon, Mar 6, 2023 at 8:06 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Mon, 6 Mar 2023 at 12:33, <marcandre.lureau@redhat.com> wrote: > > > > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > > > Make the resulting code even prettier, if possible. > > This seems to be a bit short on rationale. This is generated > code, so in general nobody is going to be reading it, and > running clang-format on it every time we generate code feels > like it would be a bit of a waste of cycles... With this reasoning, why do we care about indentation of generated code at all? I think it still makes sense, because you have many reasons to read through it eventually, and making it a bit more friendly helps. Whether it is a waste of time or not, hmm. Indeed, my experience with clang-format has teached me that it is not the most CPU-friendly sometimes... Perhaps the solution is only to enable formatting when debugging is enabled, for example? -- Marc-André Lureau
On Mon, 6 Mar 2023 at 18:29, Marc-André Lureau <marcandre.lureau@gmail.com> wrote: > > Hi > > On Mon, Mar 6, 2023 at 8:06 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Mon, 6 Mar 2023 at 12:33, <marcandre.lureau@redhat.com> wrote: > > > > > > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > > > > > Make the resulting code even prettier, if possible. > > > > This seems to be a bit short on rationale. This is generated > > code, so in general nobody is going to be reading it, and > > running clang-format on it every time we generate code feels > > like it would be a bit of a waste of cycles... > > With this reasoning, why do we care about indentation of generated code at all? > > I think it still makes sense, because you have many reasons to read > through it eventually, and making it a bit more friendly helps. Yeah, sometimes you have to read through it, so not printing it all one one long line is helpful. But it's a tradeoff -- "make it basically kinda readable by tracking indent level" is easy and quick; running the whole output through a pretty-printer is more expensive and doesn't improve the output by very much over what we already have. (If I'm wrong about that last part, it would be useful for the commit message to give an example of currently unreadable output that clang-format makes more usable.) thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes:
> On Mon, 6 Mar 2023 at 18:29, Marc-André Lureau
> <marcandre.lureau@gmail.com> wrote:
>>
>> Hi
>>
>> On Mon, Mar 6, 2023 at 8:06 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>> >
>> > On Mon, 6 Mar 2023 at 12:33, <marcandre.lureau@redhat.com> wrote:
>> > >
>> > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
>> > >
>> > > Make the resulting code even prettier, if possible.
>> >
>> > This seems to be a bit short on rationale. This is generated
>> > code, so in general nobody is going to be reading it, and
>> > running clang-format on it every time we generate code feels
>> > like it would be a bit of a waste of cycles...
>>
>> With this reasoning, why do we care about indentation of generated code at all?
>>
>> I think it still makes sense, because you have many reasons to read
>> through it eventually, and making it a bit more friendly helps.
>
> Yeah, sometimes you have to read through it, so not printing
I have to read it frequently enough to make ugly code painful.
> it all one one long line is helpful. But it's a tradeoff --
> "make it basically kinda readable by tracking indent level" is
> easy and quick; running the whole output through a pretty-printer
> is more expensive and doesn't improve the output by very much
> over what we already have. (If I'm wrong about that last part,
> it would be useful for the commit message to give an example
> of currently unreadable output that clang-format makes more usable.)
Tracking indent level is certainly quick, but it can take a bit of
effort. In review of v3, I asked for more effort, and Marc-André
floated the idea of leaving the job to readily available clang-format
instead:
ok, I improved the indentation a bit.
However, I think it would be simpler, and better, if we piped the
generated code to clang-format (when available). I made a simple patch
for that too.
My reply was
Piping through indent or clang-format may well give us neater results
for less effort.
We might want to dumb down generator code then.
Message-ID: <87356yq9rs.fsf@pond.sub.org>
https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06311.html
v4 no longer contains the indentation issue that triggered this
exchange. Let's treat this patch as if it was separate, so it doesn't
delay the remainder of the series.
You're certainly right to ask for an assessment of costs and benefits.
Costs:
* Yet another dependency, albeit optional
* Running the indenter (not sure it's noticable, but numbers wanted)
Benefits:
* Result is maybe tidier (examples wanted)
* Not in this patch: we could dumb down the code generator some (the
dependency becomes de facto mandatory for serious QAPI developers
then)
We may choose to shelve this patch until the next time decent formatting
takes us effort.
© 2016 - 2026 Red Hat, Inc.