From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnTwF-0004zD-77 for qemu-devel@nongnu.org; Wed, 29 Apr 2015 11:30:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnTwC-00070Y-Hk for qemu-devel@nongnu.org; Wed, 29 Apr 2015 11:30:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnTwC-00070C-A2 for qemu-devel@nongnu.org; Wed, 29 Apr 2015 11:30:12 -0400 Message-ID: <5540F902.3090200@redhat.com> Date: Wed, 29 Apr 2015 09:30:10 -0600 From: Eric Blake MIME-Version: 1.0 References: <1428775783-18082-1-git-send-email-eblake@redhat.com> <1428775783-18082-4-git-send-email-eblake@redhat.com> <87y4lb6uls.fsf@blackfin.pond.sub.org> In-Reply-To: <87y4lb6uls.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5kuCthBisoIErn6OurCQfUwhvF1pbLiFR" Subject: Re: [Qemu-devel] [PATCH v2 3/4] qapi: Correctly handle downstream extensions in more locations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, akong@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5kuCthBisoIErn6OurCQfUwhvF1pbLiFR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/29/2015 05:29 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> Now that c_var() handles '.' in downstream extension names, fix >> the generator to support such names as additional types, enums, >> members within an enum, branches of a union or alternate, and >> in arrays. >> >> - qtype =3D qtype, >> - abbrev =3D de_camel_case(name).upper(), >> - enum =3D c_var(de_camel_case(key),False).upper()) >> + qtype =3D qtype, >> + value =3D generate_enum_full_value("%sKind" %c_v= ar(name), >> + key)) >> >> ret +=3D mcgen(''' >> }; >=20 > I fixed this one in my "[PATCH RFC 06/19] qapi: Use c_enum_const() in > generate_alternate_qtypes()". >=20 > You picked just my "[PATCH RFC 02/19] qapi: Fix C identifiers generated= > for names containing '.'" into your series. Would you mind picking all= > the related patches, i.e PATCH 02-07? >=20 > qapi: Fix C identifiers generated for names containing '.' > qapi: Rename _generate_enum_string() to camel_to_upper() > qapi: Rename generate_enum_full_value() to c_enum_const() > qapi: Simplify c_enum_const() > qapi: Use c_enum_const() in generate_alternate_qtypes() > qapi: Move camel_to_upper(), c_enum_const() to closely related code Sure, I can pull in more of your patches in my v3. >> +++ b/scripts/qapi-visit.py >> @@ -44,12 +44,13 @@ static void visit_type_implicit_%(c_type)s(Visitor= *m, %(c_type)s **obj, Error * >> c_type=3Dtype_name(type)) >> >> def generate_visit_struct_fields(name, field_prefix, fn_prefix, membe= rs, base =3D None): >> + assert field_prefix =3D=3D "" >=20 > Makes me wonder why we have a field_prefix parameter. >=20 > fn_prefix is also always ""... Hmm - looks like I was debugging whether the code was dead (by whether I could trigger the assertion) and forgot to clean it up. I'll split that into a separate patch (I've already done another related cleanup that I found while reviewing this code, in commit 6540e9f). >> -def generate_visit_list(name, members): >> +def generate_visit_list(name, members, builtin=3DFalse): >> + if not builtin: >> + name =3D c_var(name) >=20 > Fun. >=20 > c_var() does two things: >=20 > (a) it protects certain words if protect=3DTrue >=20 > (b) it maps funny characters to '_'. >=20 > When builtin, (a) is unwanted, and (b) does nothing. That's why we nee= d > the conditional. >=20 > A possible alternative could be c_var(name, not builtin). Matter of > taste. >=20 > Hmm, just saw what type_name() does. Why not just >=20 > name =3D type_name(name) >=20 > ? Probably because I was just hacking until tests passed, rather than trying to go for optimal code (after all, that's what the review process is for, to find better ways to do things). Sounds like a good cleanup for v3. > If it was my patch, I'd be tempted to split it up some. Matter of > taste, feel free to keep it a single patch. I'll try and split it some for the next round. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --5kuCthBisoIErn6OurCQfUwhvF1pbLiFR 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/ iQEcBAEBCAAGBQJVQPkCAAoJEKeha0olJ0Nqlh8IAJMTCGOZbKPZDgRD1sveQU74 0XufMr2uEi1b3pIya63OjVqx88O62KtNKQPk+5LvMD+jhuLMul36Zq9MX1vcHiyn lR45PagjUMJYG67eRfVWjGGPqI2t8xo6Ar9fk2X6FNtD0qSnVRRgkZmgUW42Xcx9 J/3VzbSbsAu82ASKzOdKf91QyIsgNKAU0k6MpwOzPurnifJnswbyLSB54cHAf3S8 +mMcgFCGw/Aeu5cMZRNZ5H/jOPhpGWaOCy8j+1G2VuTawD0jcpUdZIzLns0PPztT DBxnXRwPSCP9iyajgZGWW0MnIlPlNiIsMqN+kyvB0TAyeK/qZsWq6rk65fW/8Rg= =tULn -----END PGP SIGNATURE----- --5kuCthBisoIErn6OurCQfUwhvF1pbLiFR--