From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhw7A-0006Om-Cl for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:54:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhw77-0003nc-2i for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:54:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhw76-0003nY-UA for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:54:49 -0400 From: Markus Armbruster References: <1443760312-656-1-git-send-email-eblake@redhat.com> <1443760312-656-6-git-send-email-eblake@redhat.com> Date: Fri, 02 Oct 2015 10:54:45 +0200 In-Reply-To: <1443760312-656-6-git-send-email-eblake@redhat.com> (Eric Blake's message of "Thu, 1 Oct 2015 22:31:45 -0600") Message-ID: <87eghdfy5m.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v6 05/12] qapi: Track location that created an implicit type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: marcandre.lureau@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, Michael Roth Eric Blake writes: > A future patch will enable deferred error detection in the > various QAPISchema*.check() methods (rather than the current > ad hoc parse checks). What's "deferred" about them? Perhaps simply: A future patch will move error checking into the various QAPISchema*.check() methods. > But that means the user can request > a QAPI entity that will only fail validation after it has > been initialized. I'm not sure I get this sentence. > Since all errors have to have an > associated 'info' location, we need a location to be > associated with all user-triggered implicit types. The > intuitive info to use is the location of the enclosing > entity that caused the creation of the implicit type. Yes. > 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, Yes, no errors should be reported for built-in entities. Sometimes, an error message for one entity wants to refer to some other entity. We'll have to take care not to blindly use info then. > by > setting a flag to track the completion of _def_predefineds(). Explaining the implementation here seems premature. > No change to the generated code. > > RFC: I used a class-level static flag to track whether we expected > 'info is None' when creating a QAPISchemaEntity. This is gross, > because the flag will only be set on the first QAPISchema() instance > (it works because none of our client scripts ever instantiate more > than one schema). But the only other thing I could think of would > be passing the QAPISchema instance into the constructor for each > QAPISchemaEntity, which is a lot of churn. Any better ideas on how > best to do the assertion, or should I just drop it? > > Signed-off-by: Eric Blake I'd check in QAPISchema._def_entity(). Patch looks good otherwise.