Re: [Qemu-devel] [PATCH v7 11/14] qapi: Move duplicate member checks to schema check()

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 10/12/2015 09:53 AM, Markus Armbruster wrote:
[...]
>> It would be simpler if we could make C clash only when QMP clashes.
>
> If a QMP clash always caused a C clash, life would be a bit simpler. We
> aren't going to get there (because in a flat union, hiding the members
> of the branch type behind a single pointer means those members don't
> clash with any C names of the overall union), but I can certainly try to
> make the comments explain what is going on.

(1) If QMP clashed exactly when C clashed, we'd have to think only about
one of them, and the C compiler would check for clashes statically.

(2) If a QMP clash implied a C clash, we'd only have to think about C,
and the C compiler would check statically.

(3) If a C clash implied a QMP clash, we'd only have to think about QMP.

(4) If they can clash independently, we need to think about both
independently.

We currently have (4), and having to juggle both QMP and C in my mind
has been taxing.

My remark was about (3): C clashes only when QMP clashes <=> C clash
implies QMP clash.

Your remark was about (2).  More useful than (3), but as you say not
feasible.

Do you think we can get to (3)?

>> We might want to separate out alternates.  Dunno.
>
> And to some extent, subset C already does some of that separation
> (because I try to convert from 'FooKind type' to 'qtype_code type'
> without even creating an implicit 'FooKind' enum).  It sounds like
> you're okay with any well-documented TODO warts related to alternates
> for the purposes of this subset B, especially if I can then clean those
> warts back up in subset C.  But what v8 of subset B needs to avoid is
> any warts based on simple vs. flat unions.  I can live with that.

I'm prepared to accept rephrased existing warts and additional temporary
warts when I understand why simply fixing them isn't practical or
economical.  A certain amount of hand-waving is okay.

> I'm still trying to figure out if hoisting the kind=>type rename into
> subset B makes life easier or harder (it certainly causes me more rebase
> churn, but that's not necessarily a bad thing).

Thanks!