John Snow <js...@redhat.com> writes: > On Fri, Jun 14, 2024 at 4:53 AM Markus Armbruster <arm...@redhat.com> wrote: > >> John Snow <js...@redhat.com> writes: >> >> > This helps simplify the doc generator if it doesn't have to check for >> > undocumented members. >> > >> > Signed-off-by: John Snow <js...@redhat.com> >> > --- >> > scripts/qapi/parser.py | 20 ++++++++++++++++++-- >> > 1 file changed, 18 insertions(+), 2 deletions(-) >> > >> > diff --git a/scripts/qapi/parser.py b/scripts/qapi/parser.py >> > index b1794f71e12..3cd8e7ee295 100644 >> > --- a/scripts/qapi/parser.py >> > +++ b/scripts/qapi/parser.py >> > @@ -740,8 +740,24 @@ def connect_member(self, member: 'QAPISchemaMember') >> > -> None: >> > raise QAPISemError(member.info, >> > "%s '%s' lacks documentation" >> > % (member.role, member.name)) >> > - self.args[member.name] = QAPIDoc.ArgSection( >> > - self.info, '@' + member.name, 'member') >> > + >> > + # Insert stub documentation section for missing member docs. >> > + section = QAPIDoc.ArgSection( >> > + self.info, f"@{member.name}", "member") >> >> Although I like f-strings in general, I'd pefer to stick to '@' + >> member.name here, because it's simpler. > > Tomayto, Tomahto. (OK.)
Apropos healthy vegetables: at some time, we might want to mass-convert to f-strings where they are easier to read. >> Also, let's not change 'member' to "member". Existing practice: single >> quotes for string literals unless double quotes avoid escapes. Except >> English prose (like error messages) is always in double quotes. >> > > OK. I realize I'm not consistent in this patch either, but I'll explain > that my using double quotes here is a black-ism that is sneaking in the > more I use it to auto-format my patches :) > > Maybe time for a flag day when I move scripts/qapi to python/qemu/qapi ... > > (Sorry, this type of stuff is ... invisible to me, and I really do rely on > the linters to make sure I don't do this kind of thing.) > > >> >> > + self.args[member.name] = section >> > + >> > + # Determine where to insert stub doc. >> >> If we have some member documentation, the member doc stubs clearly must >> go there. Inserting them at the end makes sense. >> >> Else we want to put them where the parser would accept real member >> documentation. >> >> "The parser" is .get_doc(). This is what it accepts (I'm prepared to >> explain this in detail if necessary): >> >> One untagged section >> >> Member documentation, if any >> >> Zero ore more tagged or untagged sections >> >> Feature documentation, if any >> >> Zero or more tagged or untagged sections >> >> If we there is no member documentation, this is >> >> One untagged section >> >> Zero ore more tagged or untagged sections >> >> Feature documentation, if any >> >> Zero or more tagged or untagged sections >> >> Note that we cannot have two adjacent untagged sections (we only create >> one if the current section isn't untagged; if it is, we extend it >> instead). Thus, the second section must be tagged or feature >> documentation. >> >> Therefore, the member doc stubs must go right after the first section. >> >> This is also where qapidoc.py inserts member documentation. >> >> > + index = 0 >> > + for i, sect in enumerate(self.all_sections): >> > + # insert after these: >> > + if sect.kind in ('intro-paragraph', 'member'): >> > + index = i + 1 >> > + # but before these: >> > + elif sect.kind in ('tagged', 'feature', >> > 'outro-paragraph'): >> > + index = i >> > + break >> >> Can you describe what this does in English? As a specification; simply >> paraphrasing the code is cheating. I tried, and gave up. >> > > It inserts after any intro-paragraph or member section it finds, but before > any tagged, feature, or outro-paragraph it finds. > > The loop breaks on the very first instance of tagged/feature/outro, exiting > immediately and leaving the insertion index set to the first occurrence of > such a section, so that the insertion will place the member documentation > prior to that section. > > The loop doesn't break when it finds intro-paragraph or members, so it'll > continue to tick upwards until it reaches the end of the list or it finds > something disqualifying. > > >> >> Above, I derived what I believe we need to do. It's simple enough: if >> we have member documentation, it starts right after the first (untagged) >> section, and the stub goes to the end of the member documentation. >> Else, the stub goes right after the first section. >> >> Code: >> >> index = 1; >> while self.all_sections[index].kind == 'member': >> index += 1 >> > > Wellp, yeah. That's certainly less code :) > > I tossed in your algorithm alongside mine and asserted they were always > equal, and they are, so... yup. I think the only possible concern here is > if there is precisely one and only one section and 1 is beyond EOL, but > that's easy to fix. It apparently doesn't happen in practice, but I can't > presently imagine why it *couldn't* happen. > > I'll just write a comment explaining the assumptions that make your algo > work (intro section always guaranteed even if empty; intro sections always > collapse into one section, members must start at i:=1 if they exist at all, > members must be contiguous.) You could assert the first section exists and is untagged. And maybe assert if we have members, the first is at index 1. >> Of course future patches I haven't seen might change the invariants in >> ways that break my simple code. We'll see. >> >> > + self.all_sections.insert(index, section) >> > + >> > self.args[member.name].connect(member) >> > >> > def connect_feature(self, feature: 'QAPISchemaFeature') -> None: >> >> > Now, for a critique of my own patch: this patch makes it difficult to audit > all of the cases where intro vs outro paragraphs sections may be ambiguous > because we automatically add members sections, so the warning yap I add > later on catches less cases. > > It's possible we may want to add a warning yap about paragraph ambiguity > directly to the parser, OR just decide we don't really care and we just > *assume* and that it's fine. > > We can discuss this pointedly on a call next time, and I'll come prepared > with examples and line numbers.... Or, if you'd prefer, you can get a > written report so you can take your time reading in silence. Let's try whatever feels easier for you first.