From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyYN-0003jh-74 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:19:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlyYJ-00066W-L6 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:19:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlyYJ-00066M-D1 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:19:35 -0400 From: Markus Armbruster References: <1444710158-8723-1-git-send-email-eblake@redhat.com> <1444710158-8723-13-git-send-email-eblake@redhat.com> Date: Tue, 13 Oct 2015 14:19:32 +0200 In-Reply-To: <1444710158-8723-13-git-send-email-eblake@redhat.com> (Eric Blake's message of "Mon, 12 Oct 2015 22:22:32 -0600") Message-ID: <87612b7ygb.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v8 12/18] qapi: Track location that created an implicit type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, Michael Roth Eric Blake writes: > A future patch will move some error checking from the parser > to the various QAPISchema*.check() methods, which run only > after parsing completes. It will thus be possible to create > a python instance representing an implicit QAPI type that > parses fine but will fail validation during check(). Since > all errors have to have an associated 'info' location, we > need a location to be associated with those implicit types. > The intuitive info to use is the location of the enclosing > entity that caused the creation of the implicit type; similar > to what was done for array types in an earlier patch. > > Note that we do not anticipate builtin types being used in > an error message (as they are not part of the user's QAPI > input, the user can't cause a semantic error in their > behavior), so we exempt those types from requiring info, by > setting a flag to track the completion of _def_predefineds(), > and tracking that flag in _def_entity(). > > No change to the generated code. > > Signed-off-by: Eric Blake > > --- > v8: rebase to earlier changes, improve comment, rework predefined > flag name > v7: better commit message and comments, fix info assertion to > use instance flag rather than ugly leaky abstraction static flag > v6: improve commit message, track implicit enum info, rebase > on new lazy array handling > --- > scripts/qapi.py | 32 ++++++++++++++++++-------------- > 1 file changed, 18 insertions(+), 14 deletions(-) > > diff --git a/scripts/qapi.py b/scripts/qapi.py > index 80c026b..c9ce9ee 100644 > --- a/scripts/qapi.py > +++ b/scripts/qapi.py > @@ -793,9 +793,9 @@ class QAPISchemaEntity(object): > # For explicitly defined entities, info points to the (explicit) > # definition. For builtins (and their arrays), info is None. > # For other arrays, info points to an explicit place that uses > - # the array (there may be more than one such place). > - # TODO For other implicitly defined entities, it should point to > - # a place that triggers implicit definition. > + # the array (there may be more than one such place). For other > + # implicitly defined entities, it points to the place that > + # triggered the implicit definition. How does info for implicitly defined arrays differ from info for other implicitly defined entities? I suspect it doesn't, and this comment should become simpler: # For explicitly defined entities, info points to the (explicit) # definition. For builtins (and their arrays), info is None. # For implicitly defined entities, info points to a place that # triggered the implicit definition (there may be more than one # such place). > self.info = info > > def c_name(self): [...]