On 04/02/2015 11:29 AM, Markus Armbruster wrote: > > * Implicit type definitions are made explicit, and given > auto-generated names. These names start with ':' so they don't > clash with the user's names. > > Example: a simple union implicitly defines an enumeration type for > its discriminator.
Given that I just tripped over a bug in my series where I failed to consider that '*name' and 'name' should be considered the same, I'm wondering if we should first update the parse engine to flatten shorthand into a canonical form (that is, get to a point where we have a list of all names and their C counterparts), rather than having to tweak lots of places in the backends to repeatedly make the same translations over and over again (stripping off leading '*', converting qapi 'default' into C 'q_default', converting qapi 'a-b' into C 'a_b', etc.). I bet some of the backend generator gets simpler if the front end reuses your work to get into a canonical form on initial parse. > +++ b/scripts/qapi-introspect.py > @@ -0,0 +1,430 @@ > + > +def make_implicit_enum_type(name, role, values): > + name = ':enum-%s-%s' % (name, role) Evidence of my python newbie-ness: Here, you are using string formatting (as in 'pattern' % arguments), in other patches, I've seen you use concatenation (would look like ':enum-' + name + '-' + role). Is there any rhyme or reason why one form should be considered over the other? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
