[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/6] qapi: Apply aliases in qobject-input-visitor

From: Markus Armbruster
Subject: Re: [PATCH v2 4/6] qapi: Apply aliases in qobject-input-visitor
Date: Fri, 19 Feb 2021 14:07:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Markus Armbruster <armbru@redhat.com> writes:

> Kevin Wolf <kwolf@redhat.com> writes:
>> Yes, don't use optional objects in the middle of the path of a wildcard
>> alias unless there is no semantic difference between empty object and
>> absent object.
> Aha!  So my spidey-sense wasn't entirely wrong.

Like optional members, union branches get visited only when the input is
shaped a certain way.  Which makes me wonder: does "don't use optional
in the middle" apply to union branches, too?

Hmm, I figure it doesn't because

* If the union is flat, there is no object: the variant members are the
  members of the branch struct type.

* If the union is simple, there is, but it's always there: 'data'.

Hope I'm not speaking in riddles.

>>                This is documented in the code, but it might actually
>> still be missing from qapi-code-gen.txt.
> I can't find it there.  Needs fixing, obviously.

"there" = qapi-code-gen.txt

> I guess checking "path of a wildcard alias crosses optional objects" is
> hard (impractical?) for the same reasons checking "alias can't resolve"
> is.
> I'd expect "alias can't resolve" to be caused by typos, incomplete
> renames, and such.  Basic testing should catch at least the typos.  Not
> ideal, but I guess it'll do, at least for now.
> Relying on testing to catch "crosses optional objects" mistakes feels
> iffier to me, because it takes more careful tests.
> Ham-fisted way to make basic tests catch it: *ignore* optional objects
> when resolving aliases.  Is this a bad idea?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]