Re: [PATCH v2 12/16] scripts/qapi: generate high-level Rust bindings

On 3/4/26 09:09, Markus Armbruster wrote:
>    The naming rules should reflect the names the generator wants to use.
>    When we add new patterns of generated names, we should update the
>    rules.  One pattern this series adds is names ending with 'Variant',
>    as I pointed out in the review of the generated code I sent yesterday.

I'll add the documentation here.

> * The user's names clashing with themselves.
> 
>    Naming rules again help avoid such clashes.
> 
>    Example: struct members 'a_b and 'a-b' would both map to C identifier
>    a_b if we didn't reject that.  Test case struct-member-name-clash.
> 
>    The rejection code checks for clashes among the values of c_name().
>    This guards against clashes in generated C.  To also guard against
>    clashes in generated Rust, we'd need to check the values of rs_name().
>    I'd accept a TODO comment for now.

Ok, it seems as simple as parameterizing check() and check_clash() and 
calling it twice.  Will see if that's true.

>>>>     def to_camel_case(value: str) -> str:
>>>>         result = ''
>>>>         for p in re.split(r'[-_]+', value):
>>>>             if not p:
>>>>                 pass
>>>>             elif p[0].isalpha() or (result and result[-1].isalpha()):
>>>>                 result += p[0].upper() + p[1:]
>>>>             else:
>>>>                 result += '_' + p
>>>>         return result
>>>
>>> Maps '0123-45' to '_0123_45'.  Is the leading '_' intentional?
>>
>> Yes, because otherwise the output is not an identifier; but it doesn't
>> matter since the input is actually an identifier already and
>> to_camel_case('_0123_45') does give '_0123_45'. In neither case you
>> get the invalid identifier '0123_45'.
> 
> Shouldn't that be left to rs_name()?

Ok.


>> Yeah, I will drop it. I changed mcgen to allow removing empty lines in
>> the middle of a declaration
>>
>> For the case of a single argument, the result is equivalent to the
>> existing implementation
> 
> I wonder how the generated C would change if we used this there.
It doesn't, the new function is a superset of the old one.