From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhJpp-00089D-EN for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:02:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhJpj-00069n-E2 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:02:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhJpj-00069H-7L for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:02:19 -0400 References: <1442872682-6523-1-git-send-email-eblake@redhat.com> <1442872682-6523-13-git-send-email-eblake@redhat.com> <87fv1yhfdm.fsf@blackfin.pond.sub.org> <560A0D9D.9000303@redhat.com> <87h9mdslfb.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <560C0785.7050603@redhat.com> Date: Wed, 30 Sep 2015 10:02:13 -0600 MIME-Version: 1.0 In-Reply-To: <87h9mdslfb.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kox4Vj9xH9tAtbCnqjkJ1H9Lsq1i0Rm6r" Subject: Re: [Qemu-devel] [PATCH v5 12/46] qapi: Track location that created an implicit type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Michael Roth , marcandre.lureau@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, DirtY.iCE.hu@gmail.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kox4Vj9xH9tAtbCnqjkJ1H9Lsq1i0Rm6r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/29/2015 02:02 AM, Markus Armbruster wrote: >>>> While at it, we were always passing None as the location of >>>> array types, making that parameter useless; sharing the >>>> location (if any) of the underlying element type makes sense. >>> >>> The parameter is useless only because all array types are implicit. >>> Once we change that, it won't be anymore. >> >> I guess it depends whether I pass in the existing info when creating t= he >> array or determine the info when resolving the string name of the arra= y >> element during check() (it will ultimately be the same info either way= , >> it's just a question of which approach looks cleaner for getting the >> information set). >=20 > The latter leaves info None until check(). Unhealthy state. >=20 > I suspect the appropriate info is readily available in all the places > where we create array types, so let's just pass it to > _make_array_type(). I just realized why I left it None until check(). We can have forward references to arrays, as in: { 'struct':'A', 'data':{ 'list': ['B'] } } { 'struct':'B', 'data':{ 'value': 'int' } } Normally, BList gets created at the same time as B (and so logically shares the location of B), but with forward references, we have the problem that _make_member() has no access to info (unless I plumb it in), and even if it did, it would be the info for A, whereas my check() methodology used the info for B. That is, _make_array_type() does not yet have ready access to info in all call sites. On the other hand, we have the big TODO about whether pre-creating array types is even necessary, and want to consider lazy array creation where they are only instantiated if actually used by a member type or command return value. I guess it's time for me to play with doing that cleanup first, and then I'd be happy to have an array's info be the info of its first instantiation, rather than the info of its element type. (And that means that ['int'] would have an info, if an array of ints is used anywhere, even though 'int' does not.) > Back to serious. If we have to work for the assertion, we should > consider the assertion's value: how likely are the actual mistakes it > can catch? >=20 > Can legitimate errors be reported for built-in types? I don't think so (and in fact have assertions along those lines) - we can only report a semantic error about something in the user's QAPI file, but their file didn't define the builtin types, so I don't see how we would ever want to report a semantic error at the location tracked by a builtin type. So we should be safe if builtin types use info=3DNone. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --kox4Vj9xH9tAtbCnqjkJ1H9Lsq1i0Rm6r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWDAeFAAoJEKeha0olJ0NqzM8IALASYGMX9OdlWWbtCdV4GJ+U sRmiaN0M6njl07JbJ5H2IELT9Xd3j0SDwkMI1Cf5Uk/ZK+89eDXJYJpeFuqAe+3B 0jNulYWFYT15qxFvKy0oYr6jLyb03q7B0R5uqARa9S3+bjwFnhGrwWsO5/x9XVBD KW14FkVyNgqnvgtwiW1yTEY2FmOIFnNAg8SE67vcIJ6T4n2TORZb6Rdd7tNWQuIr wJuR8Bg3Q/+teIBBp2CrbgDkzAQdEiZmIpb7m2TSn9M69r0LgeTeOSKJaOz9Zl6K joekCdF360m+8YTWjPIaGLhNpDgyZFBFtBrKQ7nqVNOSseDsWm9neRR46TaZ7pc= =h/lI -----END PGP SIGNATURE----- --kox4Vj9xH9tAtbCnqjkJ1H9Lsq1i0Rm6r--