On Wed, Feb 22, 2023 at 11:23:03AM +0100, Markus Armbruster wrote:
> > 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.
>
> Piping through indent or clang-format may well give us neater results
> for less effort.
>
> We might want to dumb down generator code then.
Indeed, this approach seems like it might be worth pursuing (our
generator doesn't have to worry about spacing, because we do that in a
second pass with something that will still produce human-legible final
results).
> >> > So I would rather assert that we don't introduce such a schema, until we
> >> > fix the code generator. Or we acknowledge the limitation, and treat it
> >> > as a
> >> > schema error. Other ideas?
> >>
> >> Yes: throw an error. Assertions are for programming errors. This isn't
> >> a programming error, it's a limitation of the current implementation.
> >>
> >> How hard would it be to lift the limitation?
> >
> > Taking this as a problematic example:
> >
> > void function(first,
> > #ifdef A
> > a,
> > #endif
> > #ifdef B
> > b
> > #endif
> > )
I am NOT a fan of preprocessor conditionals mid-function-signature.
It gets really nasty, really fast. Is there any way we can have:
struct S {
#ifdef A
type a;
#endif
#ifdef B
type b;
#endif
};
void function(struct S)
so that the preprocessor conditionals never appear inside ()?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
