| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | tests/qapi-schema: Rename tests from data- to args- | Markus Armbruster | 2015-09-04 | 1 | -5/+0![]() |
| | | | | | | | | | | Since every schema entity has 'data', the data- prefix conveys no information. These tests actually exercise commands. Only commands have arguments, so change the prefix to to args-. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> | ||||
| * | qapi: Prefer 'struct' over 'type' in generator | Eric Blake | 2015-05-05 | 1 | -2/+2 |
| | | | | | | | | | | | | | | | | | | | | | | | | Referring to "type" as both a meta-type (built-in, enum, union, alternate, or struct) and a specific type (the name that the schema uses for declaring structs) is confusing. The confusion is only made worse by the fact that the generator mostly already refers to struct even when dealing with expr['type']. This commit changes the generator to consistently refer to it as struct everywhere, plus a single back-compat tweak that allows accepting the existing .json files as-is, so that the meat of this change is separate from the mindless churn of that change. Fix the testsuite fallout for error messages that change, and in some cases, become more legible. Improve comments to better match our intentions where a struct (rather than any complex type) is required. Note that in some cases, an error message now refers to 'struct' while the schema still refers to 'type'; that will be cleaned up in the later commit to the schema. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> | ||||
| * | qapi: Add some type check tests | Eric Blake | 2015-05-05 | 1 | -0/+5 |
| Demonstrate that the qapi generator silently parses confusing types, which may cause other errors later on. Later patches will update the expected results as the generator is made stricter. Most of the new tests focus on blatant errors. But returns-whitelist is a case where we have historically allowed returning something other than a JSON object from particular commands; we have to keep that behavior to avoid breaking clients, but it would be nicer to avoid adding such commands in the future, because any return that is not an (array of) object cannot be easily extended if future qemu wants to return additional information. The QMP protocol already documents that clients should ignore unknown dictionary keys, but does not require clients to have to handle more than one type of JSON object. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> | |||||

