| Message ID | 55EAEBDF.5070704@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 09/05/2015 07:19 AM, Eric Blake wrote: > On 09/04/2015 05:51 PM, Eric Blake wrote: >> We have a few fields that exist mainly to hold information from >> __init__() until check() (matching the fact that parsing is >> two-pass; the first to find type names, the second to associate >> types together while honoring forward references), or which should >> only be used through accessor methods. We should not use these >> fields directly in other files after check() has run, so use the >> python convention of naming these fields with leading underscore >> to mark their internal usage, and to check that no one else was >> using them. >> >> Exception: our crazy handling of simple unions (with a C member >> 'kind' matching the QMP wire 'type') requires peeking through >> the hidden field. This leaky abstraction will be cleaned up in >> a later patch. >> >> Signed-off-by: Eric Blake <eblake@redhat.com> >> --- >> >> Technically, I wrote this patch after 32; if you decide to rebase >> it into the series, you'll have to split it among 2, 10, 11, and 30. >> Up to you if you want to squash this in during your spin of v5, or >> if you want me to keep it as a separate patch for inclusion after >> your series. > > Oh, and tests/qapi-schema/test-qapi.py is annoying - even when it exits > non-zero, it does NOT cause a failure in 'make check-qapi-schema'. Rather, it does not leave an obvious stack trace or immediate non-zero status; and 'make check-qapi-schema' only fails as a side effect if later output happens to differ from expectations. I would have had a much easier time chasing the problem if I'd had an obvious python stack trace.
On 09/05/2015 07:25 AM, Eric Blake wrote: >> >> Oh, and tests/qapi-schema/test-qapi.py is annoying - even when it exits >> non-zero, it does NOT cause a failure in 'make check-qapi-schema'. > > Rather, it does not leave an obvious stack trace or immediate non-zero > status; and 'make check-qapi-schema' only fails as a side effect if > later output happens to differ from expectations. I would have had a > much easier time chasing the problem if I'd had an obvious python stack > trace. Oh, I see what happened. It did capture a trace in .err; but since the code checks for differences in .out before .err, I didn't even realize there was a trace to look at.
diff --git i/tests/qapi-schema/test-qapi.py w/tests/qapi-schema/test-qapi.py index 471f8e1..0fc0622 100644 --- i/tests/qapi-schema/test-qapi.py +++ w/tests/qapi-schema/test-qapi.py @@ -40,8 +40,9 @@ class QAPISchemaTestVisitor(QAPISchemaVisitor): @staticmethod def _print_variants(variants): if variants: - if variants.tag_name: - print ' tag %s' % variants.tag_name + # TODO: fix simple unions so we don't have to look at _tag_name + if variants._tag_name: + print ' tag %s' % variants.tag_member.name for v in variants.variants: print ' case %s: %s' % (v.name, v.type.name)