From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH 06/12] qapi/source: Add builtin null-object sentinel
Date: Thu, 17 Dec 2020 12:56:44 +0100 [thread overview]
Message-ID: <87im90k5mr.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <9f25c91a-774d-fbe3-3780-5415e7a54524@redhat.com> (John Snow's message of "Wed, 16 Dec 2020 14:11:35 -0500")
John Snow <jsnow@redhat.com> writes:
> On 12/16/20 4:22 AM, Markus Armbruster wrote:
>> 2. On error with "no source info", don't crash.
>> I have my doubts on this one.
>> Such an error means the QAPI code generator screwed up, at least
>> in
>> theory. Crashing is only proper. It gets the screwup fixed.
>>
>
> QAPISemError and friends will also halt the generator and don't
> produce output and will fail tests. They aren't less visible or more
> ignorable somehow.
>
>> In practice, errors due to interactions between built-in stuff and
>> user-defined stuff could conceivably escape testing. I can't
>> remember such a case offhand.
>> Will the "no source info" error be more useful than a crash?
>> Possibly. Will it get the screwup fixed? Maybe not.
>
> I don't understand this; if it's an error -- there's no QAPI, there's
> no QEMU. It's definitely getting fixed.
>
> If QAPISourceInfo is primarily used for printing error information, we
> are already in a situation where the generator is hosed and has
> wandered itself into a problem that can't be ignored.
>
> There's no additional value in having python crash twice per every
> crash because we have bad types in our error reporting functions.
Consider the following scenario. The average developer knows just
enough about QAPI to be dangerous. That's okay; if you had to be a QAPI
expert to modify the QAPI schema, we would have failed. Now meet Joe
Average. He's a good guy. Today his job happens to require extending
the QAPI schema. In a hurry, as usual. So Joe brings his well-honed
voodoo programming skills to bear, and writes something that looks
plausible to him. His build fails. He's not surprised; he's voodoo-
programming after all. However, the error message is less clear than
usual. Something about a '[builtin]' file. There is no '[builtin]'
file. What to do? Obvious! If a bit of voodoo doesn't get you over
the finish line, use more: twiddle the schema until it works.
If his build failed with a Python backtrace instead, Joe would
immediately know that he ran into a bug in our tooling he should report.
Again, I don't mean to criticize Joe. I've walked in his shoes myself.
next prev parent reply other threads:[~2020-12-17 11:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-14 23:53 [PATCH 00/12] qapi: static typing conversion, pt1.5 John Snow
2020-12-14 23:53 ` [PATCH 01/12] qapi/commands: assert arg_type is not None John Snow
2020-12-14 23:53 ` [PATCH 02/12] qapi/events: fix visit_event typing John Snow
2020-12-14 23:53 ` [PATCH 03/12] qapi/main: handle theoretical None-return from re.match() John Snow
2020-12-16 8:23 ` Markus Armbruster
2020-12-16 17:11 ` John Snow
2020-12-14 23:53 ` [PATCH 04/12] qapi/gen: assert that _start_if is not None in _wrap_ifcond John Snow
2020-12-16 8:26 ` Markus Armbruster
2020-12-16 17:13 ` John Snow
2020-12-17 7:24 ` Markus Armbruster
2020-12-14 23:53 ` [PATCH 05/12] qapi/gen: use './builtin' for the built-in module name John Snow
2020-12-16 8:35 ` Markus Armbruster
2020-12-16 17:27 ` John Snow
2020-12-14 23:53 ` [PATCH 06/12] qapi/source: Add builtin null-object sentinel John Snow
2020-12-16 9:22 ` Markus Armbruster
2020-12-16 17:53 ` John Snow
2020-12-17 12:33 ` Markus Armbruster
2020-12-18 19:14 ` John Snow
2020-12-16 19:11 ` John Snow
2020-12-17 11:56 ` Markus Armbruster [this message]
2020-12-18 19:22 ` John Snow
2020-12-14 23:53 ` [PATCH 07/12] qapi/gen: write _genc/_genh access shims John Snow
2020-12-14 23:53 ` [PATCH 08/12] qapi/schema: make QAPISourceInfo mandatory John Snow
2020-12-16 10:18 ` Markus Armbruster
2020-12-16 18:41 ` John Snow
2020-12-17 8:02 ` Markus Armbruster
2020-12-17 17:02 ` John Snow
2020-12-18 5:24 ` Markus Armbruster
2020-12-18 19:17 ` John Snow
2020-12-18 20:57 ` Markus Armbruster
2020-12-18 21:30 ` John Snow
2020-12-14 23:53 ` [PATCH 09/12] qapi/gen: move write method to QAPIGenC, make fname a str John Snow
2020-12-16 10:31 ` Markus Armbruster
2020-12-14 23:53 ` [PATCH 10/12] tests/qapi-schema: Add quotes to module name in test output John Snow
2020-12-14 23:53 ` [PATCH 11/12] qapi/schema: Name the builtin module "" instead of None John Snow
2020-12-16 10:42 ` Markus Armbruster
2020-12-16 18:57 ` John Snow
2020-12-17 11:09 ` Markus Armbruster
2020-12-17 21:07 ` John Snow
2020-12-18 5:31 ` Markus Armbruster
2020-12-14 23:53 ` [PATCH 12/12] qapi: enable strict-optional checks John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im90k5mr.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.