On 03/26/2015 09:55 AM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
> 
>> Demonstrate that the qapi generator doesn't deal well with
>> expressions that aren't up to par. Later patches will improve
>> the expected results as the generator is made stricter.  Only
>> one of the added tests actually behaves sanely at rejecting
>> obvious problems.
>>
> 
> qapi-code-gen.txt documents the naming conventions:
> 
>     Types, commands, and events share a common namespace.  Therefore,
>     generally speaking, type definitions should always use CamelCase for
>     user-defined type names, while built-in types are lowercase. Type
>     definitions should not end in 'Kind', as this namespace is used for
>     creating implicit C enums for visiting union types.  Command names,
>     and field names within a type, should be all lower case with words
>     separated by a hyphen.  However, some existing older commands and
>     complex types use underscore; when extending such expressions,
>     consistency is preferred over blindly avoiding underscore.  Event
>     names should be ALL_CAPS with words separated by underscore.  The
>     special string '**' appears for some commands that manually perform
>     their own type checking rather than relying on the type-safe code
>     produced by the qapi code generators.
> 
> We should either enforce the conventions consistently, or not at all.
> 
> Enforcing them makes certain kinds of name clashes in generated C
> impossible.  If we don't enforce them, we should catch the clashes.
> 
> Since I haven't read to the end of your series, I have to ask: do you
> intend to enforce them?

I added tests to enforce it for event names, but did not enforce things
for command names or complex type members.  I guess that can be added on
top, if desired.

So, did this patch get R-b?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org