Re: [PATCH v2 00/44] qapi: convert trivial intro sections

Markus Armbruster <[email protected]> Tue, 28 Jul 2026 16:03:38 +0200
Newsgroups org.nongnu.qemu-trivial,org.kernel.vger.linux-cxl,org.kernel.vger.linux-edac,org.nongnu.qemu-devel
Message-ID <[email protected]>
John Snow <[email protected]> writes:

> On Fri, Jul 24, 2026 at 4:04=E2=80=AFAM Markus Armbruster <armbru@redhat.=
com> wrote:
>>
>> Markus Armbruster <[email protected]> writes:
>>
>> [...]
>>
>> > Converting single first paragraps is mechanical.  For it to be correct=
,
>> > this single paragraph must actually be the overview, and not some othe=
r
>> > crap.  I expect it to be almost always overview.  Not sure how to best
>> > look for the exceptions.
>>
>> The separation truly matters only when the inliner inlines the doc
>> comment.  It potentially matters when it would inline it if the type was
>> used differently.
>
> It also (potentially) matters for auto-generated docs, such as
> undocumented members, return types, features*, errors*. The break
> point is where these fields get inserted.

Right, I forgot about this.  There goes my review shortcut...

> (*Not currently performed. Not asserting that it will be performed, or
> that it is necessarily valuable to do so. Just fleshing out the
> category.)
>
>>
>> If I remember correctly, the inliner inlines doc of struct / union base
>> type, union branch type, command / event argument type.
>>
>> Argument can only be struct or union.  Base and branch can only be
>> struct.
>>
>> We talked about maybe inlining return types some day.  This would be
>> struct, union, or array of struct or union.
>>
>> So, for anything other than struct and union, the inliner doesn't get
>> involved, and separating the overview cleanly is just a matter of
>> writing style.  I'm not sure we care.  Even if we elect to care,
>> cleaning it up is hardly this series' business.  In short, your
>> mechanical conversion of single first paragraphs to overview syntax
>> should be fine even where a paragraph's contents isn't clearly overview.
>
> Except in cases where stub positioning matters, see also the former
> "TODO:" syntax used to delineate intro/details.
>
>>
>> Structs and unions, however, could use an eye-over.
>>
>> [...]
>>