On Tue, Sep 29, 2026, 7:49 AM Markus Armbruster <[email protected]> wrote:
> John Snow <[email protected]> writes: > > > With this change, we no longer have "plaintext" sections at all: they > > are all now either "Intro" or "Details". This patch does not enforce > > where those details sections must occur; that change occurs in a later > > patch. > > > > Signed-off-by: John Snow <[email protected]> > > --- > > docs/sphinx/qapidoc.py | 2 +- > > scripts/qapi/parser.py | 18 +++++++++++------- > > tests/qapi-schema/doc-good.out | 18 +++++++++--------- > > 3 files changed, 21 insertions(+), 17 deletions(-) > > > > diff --git a/docs/sphinx/qapidoc.py b/docs/sphinx/qapidoc.py > > index 54a32e45f7e..ae57056a393 100644 > > --- a/docs/sphinx/qapidoc.py > > +++ b/docs/sphinx/qapidoc.py > > @@ -383,7 +383,7 @@ def visit_sections(self, ent: QAPISchemaDefinition) > -> None: > > for section in sections: > > section.text = self.reformat_arobase(section.text) > > > > - if section.kind.name in ("PLAIN", "INTRO"): > > + if section.kind.name in ("INTRO", "DETAILS"): > > self.visit_plaintext(section) > > elif section.kind == QAPIDoc.Kind.MEMBER: > > assert isinstance(section, QAPIDoc.ArgSection) > > diff --git a/scripts/qapi/parser.py b/scripts/qapi/parser.py > > index dcc04b2663e..fe284a3f866 100644 > > --- a/scripts/qapi/parser.py > > +++ b/scripts/qapi/parser.py > > @@ -674,7 +674,7 @@ class QAPIDoc: > > """ > > > > class Kind(enum.Enum): > > - PLAIN = 0 > > + DETAILS = 0 > > MEMBER = 1 > > FEATURE = 2 > > RETURNS = 3 > > I'd like the order of enum values to match the order of sections > eventually. > I've got a treat for you from the future! > > @@ -747,12 +747,16 @@ def has_features(self) -> bool: > > def end(self) -> None: > > for section in self.all_sections: > > section.text = section.text.strip('\n') > > - if not (section.kind.name in ("INTRO", "PLAIN") or > section.text): > > + if ( > > + section.kind not in ( > > + QAPIDoc.Kind.INTRO, QAPIDoc.Kind.DETAILS > > + ) and section.text == '' > > + ): > > This isn't just rename. > > The old conditional is a bit "uh, why bother with enums if we do strings > anyway". The conditional is ugly. > > Are empty DETAILS even possible? Got a reproducer? > Mmm.... I'm afraid of dragons. I can investigate, ... > If not, you could use > > if section.text == '' and section.kind != > QAPIDoc.Kind.INTRO: > > > raise QAPISemError( > > section.info, "text required after '%s:'" % > section.kind) > > > > def ensure_untagged_section(self, info: QAPISourceInfo) -> None: > > - kind = QAPIDoc.Kind.PLAIN > > + kind = QAPIDoc.Kind.DETAILS > > > > if self.all_sections and self.all_sections[-1].kind == kind: > > # extend current section > > @@ -837,8 +841,8 @@ def _insert_after_intro( > > """ > > Insert a section immediately after the intro section. > > > > - While we convert PLAIN sections to INTRO sections, all > > - contiguous INTRO/PLAIN sections at the start of a QAPIDoc > > + While we convert DETAILS sections to INTRO sections, all > > + contiguous INTRO/DETAILS sections at the start of a QAPIDoc > > section list are treated as "the intro". > > > > Once INTRO conversion is complete, this helper will no longer be > > This goes away in PATCH 9. I'd be tempted to delay the rename until > after that. Up to you. > I'll look. > > @@ -855,7 +859,7 @@ def _insert_after_intro( > > > > index = 0 > > for index, ref_section in enumerate(self.all_sections): > > - if ref_section.kind.name in ("PLAIN", "INTRO"): > > + if ref_section.kind.name in ("INTRO", "DETAILS"): > > continue > > break > > else: > > @@ -871,7 +875,7 @@ def append_member_stub(self, stub: > 'QAPIDoc.Section') -> None: > > if self._insert_near_kind(QAPIDoc.Kind.MEMBER, stub, True): > > return > > > > - # No MEMBER sections present. Insert after INTRO/PLAIN sections. > > + # No MEMBER sections present. Insert after INTRO/DETAILS > sections. > > self._insert_after_intro(stub) > > > > def connect_member(self, member: 'QAPISchemaMember') -> None: > > diff --git a/tests/qapi-schema/doc-good.out > b/tests/qapi-schema/doc-good.out > > index eaaf119dea8..1d4fbd3762a 100644 > > [...] > >
