summaryrefslogtreecommitdiffstats
path: root/tests/qapi-schema
Commit message (Collapse)AuthorAgeFilesLines
* qapi: Simplify error reporting for array typesMarkus Armbruster2015-09-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | check_type() first checks and peels off the array type, then checks the element type. For two out of four error messages, it takes pains to report errors for "array of T" instead of just T. Odd. Let's examine the errors. * Unknown element type, e.g. tests/qapi-schema/args-array-unknown.json: Member 'array' of 'data' for command 'oops' uses unknown type 'array of NoSuchType' To make sense of this, you need to know that 'array of NoSuchType' refers to '[NoSuchType]'. Easy enough. However, simply reporting Member 'array' of 'data' for command 'oops' uses unknown type 'NoSuchType' is at least as easy to understand. * Element type's meta-type is inadmissible, e.g. tests/qapi-schema/returns-whitelist.json: 'returns' for command 'no-way-this-will-get-whitelisted' cannot use built-in type 'array of int' 'array of int' is technically not a built-in type, but that's pedantry. However, simply reporting 'returns' for command 'no-way-this-will-get-whitelisted' cannot use built-in type 'int' avoids the issue, and is at least as easy to understand. * The remaining two errors are unreachable, because the array checking ensures that value is a string. Thus, reporting some errors for "array of T" instead of just T works, but doesn't really improve things. Drop it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Fix errors for non-string, non-dictionary membersMarkus Armbruster2015-09-046-6/+3
| | | | | | | Fixes the errors demonstrated by the previous commit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: Cover non-string, non-dictionary membersMarkus Armbruster2015-09-0412-0/+15
| | | | | | | | | We always report "should be a dictionary" then. This is misleading: when allow_dict, it can be a dictionary or a type name string, else it can only be a type name. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: Cover two more syntax errorsMarkus Armbruster2015-09-048-0/+8
| | | | | | | Syntax error coverage should now be complete. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Drop one of two "simple union must not have base" checksMarkus Armbruster2015-09-041-1/+1
| | | | | | | | | The first check ensures the second one can't trigger. Drop the first one, because the second one is in a more logical place, and emits a nicer error message. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Command returning anonymous type doesn't work, outlawMarkus Armbruster2015-09-048-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Reproducer: with { 'command': 'user_def_cmd4', 'returns': { 'a': 'int' } } added to qapi-schema-test.json, qapi-commands.py dies when it tries to generate the command handler function Traceback (most recent call last): File "/work/armbru/qemu/scripts/qapi-commands.py", line 359, in <module> ret = generate_command_decl(cmd['command'], arglist, ret_type) + "\n" File "/work/armbru/qemu/scripts/qapi-commands.py", line 29, in generate_command_decl ret_type=c_type(ret_type), name=c_name(name), File "/work/armbru/qemu/scripts/qapi.py", line 927, in c_type assert isinstance(value, str) and value != "" AssertionError because the return type doesn't exist. Simply outlaw this usage, and drop or dumb down test cases accordingly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Fix to reject union command and event argumentsMarkus Armbruster2015-09-044-6/+3
| | | | | | | | | | | | | | A command's or event's 'data' must be a struct type, given either as a dictionary, or as struct type name. Commit dd883c6 tightened the checking there, but not enough: we still accept 'union'. Fix to reject it. We may want to support union types there, but we'll have to extend qapi-commands.py and qapi-events.py for it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi-tests: New tests for union, alternate command argumentsMarkus Armbruster2015-09-048-0/+14
| | | | | | | | | | | | | | | | A command's 'data' must be a struct type, given either as a dictionary, or as struct type name. Existing test case data-int.json covers simple type 'int'. Add test cases for type names referring to union and alternate types. The latter is caught (good), but the former is not (bug). Events have the same problem, but since they get checked by the same code, we don't bother to duplicate the tests. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: Rename tests from data- to args-Markus Armbruster2015-09-0431-6/+6
| | | | | | | | | 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>
* tests/qapi-schema: Restore test case for flat union base bugMarkus Armbruster2015-09-042-6/+7
| | | | | | | Test case added in commit 2fc0043, and messed up in commit 5223070. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: Document events with base don't workMarkus Armbruster2015-09-041-0/+3
| | | | | | | | | | | When event FOO's 'data' is a struct with a base, we consider only the struct's direct members, and ignore its base. The generated qapi_event_send_foo() doesn't take arguments for base members. No such events currently exist in the QMP schema. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: Document alternate's enum lacks visit functionMarkus Armbruster2015-09-041-0/+1
| | | | | | | | | | | We generate a declaration, but no definition. The QMP schema has two: Qcow2OverlapChecks and BlockdevRef. Neither visit_type_Qcow2OverlapChecksKind() nor visit_type_BlockdevRefKind() is actually used. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi-visit: Fix generated code when schema has forward refsMarkus Armbruster2015-09-042-18/+22
| | | | | | | | | | | | | | | | | | The visit_type_implicit_FOO() are generated on demand, right before their first use. Used by visit_type_STRUCT_fields() when STRUCT has base FOO, and by visit_type_UNION() when flat UNION has member a FOO. If the schema defines FOO after its first use as struct base or flat union member, visit_type_implicit_FOO() calls visit_type_implicit_FOO() before its definition, which doesn't compile. Rearrange qapi-schema-test.json to demonstrate the bug. Fix by generating the necessary forward declaration. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Catch and reject flat union branch of array typeMarkus Armbruster2015-06-181-10/+1
| | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* tests/qapi-schema: New flat union array branch test caseMarkus Armbruster2015-06-184-0/+23
| | | | | | | The new test demonstrates another generator crash. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Fix file name in error messages for included filesMarkus Armbruster2015-06-182-3/+3
| | | | | | | | | We print the name as it appears in the include expression. Tools processing error messages want it relative to the working directory. Make it so. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi: Support downstream events and commandsEric Blake2015-05-142-1/+8
| | | | | | | | | | | Enhance the testsuite to cover downstream events and commands. Events worked without more tweaks, but commands needed a few final updates in the generator to mangle names in the appropriate places. In making those tweaks, it was easier to drop type_visitor() and inline its actions instead. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support downstream alternatesEric Blake2015-05-142-2/+6
| | | | | | | | | Enhance the testsuite to cover downstream alternates, including whether the branch name or type is downstream. Update the generator to mangle alternate names in the appropriate places. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support downstream flat unionsEric Blake2015-05-142-2/+10
| | | | | | | | | | Enhance the testsuite to cover downstream flat unions, including the base type, discriminator name and type, and branch name and type. Update the generator to mangle the union names in the appropriate places. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support downstream simple unionsEric Blake2015-05-142-2/+5
| | | | | | | | | Enhance the testsuite to cover downstream simple unions, including when a union branch is a downstream name. Update the generator to mangle the union names in the appropriate places. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support downstream structsEric Blake2015-05-142-2/+10
| | | | | | | | | Enhance the testsuite to cover downstream structs, including struct members and base structs. Update the generator to mangle the struct names in the appropriate places. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support downstream enumsEric Blake2015-05-142-1/+6
| | | | | | | | | Enhance the testsuite to cover a downstream enum type and enum string. Update the generator to mangle the enum name in the appropriate places. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Check for member name conflicts with a base classEric Blake2015-05-0512-12/+23
| | | | | | | | | | | | | | | | | | | | Our type inheritance for both 'struct' and for flat 'union' merges key/value pairs from the base class with those from the type in question. Although the C code currently boxes things so that there is a distinction between which member is referred to, the QMP wire format does not allow passing a key more than once in a single object. Besides, if we ever change the generated C code to not be quite so boxy, we'd want to avoid duplicate member names there, too. Fix a testsuite entry added in an earlier patch, as well as adding a couple more tests to ensure we have appropriate coverage. Ensure that collisions are detected, regardless of whether there is a difference in opinion on whether the member name is optional. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Support (subset of) \u escapes in stringsEric Blake2015-05-0524-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | The handling of \ inside QAPI strings was less than ideal, and really only worked JSON's \/, \\, \", and our extension of \' (an obvious extension, when you realize we use '' instead of "" for strings). For other things, like '\n', it resulted in a literal 'n' instead of a newline. Of course, at the moment, we really have no use for escaped characters, as QAPI has to map to C identifiers, and we currently support ASCII only for that. But down the road, we may add support for default values for string parameters to a command or struct; if that happens, it would be nice to correctly support all JSON escape sequences, such as \n or \uXXXX. This gets us closer, by supporting Unicode escapes in the ASCII range. Since JSON does not require \OCTAL or \xXX escapes, and our QMP implementation does not understand them either, I intentionally reject it here, but it would be an easy addition if we desired it. Likewise, intentionally refusing the NUL byte means we don't have to worry about C strings being shorter than the qapi input. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Drop support for inline nested typesEric Blake2015-05-059-11/+7
| | | | | | | | | | | | | | A future patch will be using a 'name':{dictionary} entry in the QAPI schema to specify a default value for an optional argument (see previous commit messages for more details why); but existing use of inline nested structs conflicts with that goal. Now that all commands have been changed to avoid inline nested structs, nuke support for them, and turn it into a hard error. Update the testsuite to reflect tighter parsing rules. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Drop tests for inline nested structsEric Blake2015-05-052-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A future patch will be using a 'name':{dictionary} entry in the QAPI schema to specify a default value for an optional argument; but existing use of inline nested structs conflicts with that goal. More precisely, a definition in the QAPI schema associates a name with a set of properties: Example 1: { 'struct': 'Foo', 'data': { MEMBERS... } } associates the global name 'Foo' with properties (meta-type struct) and MEMBERS... Example 2: 'mumble': TYPE within MEMBERS... above associates 'mumble' with properties (type TYPE) and (optional false) within type Foo The syntax of example 1 is extensible; if we need another property, we add another name/value pair to the dictionary (such as 'base':TYPE). The syntax of example 2 is not extensible, because the right hand side can only be a type. We have used name encoding to add a property: "'*mumble': 'int'" associates 'mumble' with (type int) and (optional true). Nice, but doesn't scale. So the solution is to change our existing uses to be syntactic sugar to an extensible form: NAME: TYPE --> NAME: { 'type': TYPE, 'optional': false } *ONAME: TYPE --> ONAME: { 'type': TYPE, 'optional': true } This patch fixes the testsuite to avoid inline nested types, by breaking the nesting into explicit types; it means that the type is now boxed instead of unboxed in C code, but makes no difference on the wire (and if desired, a later patch could change the generator to not do so much boxing in C). When touching code to add new allocations, also convert existing allocations to consistently prefer typesafe g_new0 over g_malloc0 when a type name is involved. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Merge UserDefTwo and UserDefNested in testsEric Blake2015-05-052-12/+4
| | | | | | | | | | | | | | | | In the testsuite, UserDefTwo and UserDefNested were identical structs other than the member names. Reduce code duplication by having just one type, and choose names that also favor reuse. This will also make it easier for a later patch to get rid of inline nested types in QAPI. When touching code related to allocations, convert g_malloc0(sizeof(Type)) to the more typesafe g_new0(Type, 1). Ensure that 'make check-qapi-schema check-unit' still passes. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Use 'struct' instead of 'type' in schemaEric Blake2015-05-0533-66/+66
| | | | | | | | | | | | | | | | | | | | | | 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. Do the bulk of the conversion to "struct" in qapi schema, with a fairly mechanical: for f in `find -name '*.json'; do sed -i "s/'type'/'struct'/"; done followed by manually filtering out the places where we have a 'type' embedded in 'data'. Then tweak a couple of tests whose output changes slightly due to longer lines. I also verified that the generated files for QMP and QGA (such as qmp-commands.h) are the same before and after, as assurance that I didn't leave in any accidental member name changes. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Prefer 'struct' over 'type' in generatorEric Blake2015-05-0519-52/+52
| | | | | | | | | | | | | | | | | | | | | | | 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: More rigorous checking for type safety bypassEric Blake2015-05-058-10/+6
| | | | | | | | | | | | | | | | | | | | Now that we have a way to validate every type, we can also be stricter about enforcing that callers that want to bypass type safety in generated code. Prior to this patch, it didn't matter what value was associated with the key 'gen', but it looked odd that 'gen':'yes' could result in bypassing the generated code. These changes also enforce the changes made earlier in the series for documentation and consolidation of using '**' as the wildcard type, as well as 'gen':false as the canonical spelling for requesting type bypass. Note that 'gen':false is a one-way switch away from the default; we do not support 'gen':true (similar for 'success-response'). In practice, this doesn't matter. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Whitelist commands that don't return dictionaryEric Blake2015-05-0510-17/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...or an array of dictionaries. Although we have to cater to existing commands, returning a non-dictionary means the command is not extensible (no new name/value pairs can be added if more information must be returned in parallel). By making the whitelist explicit, any new command that falls foul of this practice will have to be self-documenting, which will encourage developers to either justify the action or rework the design to use a dictionary after all. It's a little bit sloppy that we share a single whitelist among three clients (it's too permissive for each). If this is a problem, a future patch could tighten things by having the generator take the whitelist as an argument (as in scripts/qapi-commands.py --legacy-returns=...), or by having the generator output C code that requires explicit use of the whitelist (as in: #ifndef FROBNICATE_LEGACY_RETURN_OK # error Command 'frobnicate' should return a dictionary #endif then having the callers define appropriate macros). But until we need such fine-grained separation (if ever), this patch does the job just fine. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Require valid namesEric Blake2015-05-0518-26/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous commits demonstrated that the generator overlooked various bad naming situations: - types, commands, and events need a valid name - enum members must be valid names, when combined with prefix - union and alternate branches cannot be marked optional Valid upstream names match [a-zA-Z][a-zA-Z0-9_-]*; valid downstream names match __[a-zA-Z][a-zA-Z0-9._-]*. Enumerations match the weaker [a-zA-Z0-9._-]+ (in part thanks to QKeyCode picking an enum that starts with a digit, which we can't change now due to backwards compatibility). Rather than call out three separate regex, this patch just uses a broader combination that allows both upstream and downstream names, as well as a small hack that realizes that any enum name is merely a suffix to an already valid name prefix (that is, any enum name is valid if prepending _ fits the normal rules). We could reject new enumeration names beginning with a digit by whitelisting existing exceptions. We could also be stricter about the distinction between upstream names (no leading underscore, no use of dot) and downstream (mandatory leading double underscore), but it is probably not worth the bother. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: More rigourous checking of typesEric Blake2015-05-0551-68/+39
| | | | | | | | | | | | | | | | | | Now that we know every expression is valid with regards to its keys, we can add further tests that those keys refer to valid types. With this patch, all uses of a type (the 'data': of command, type, union, alternate, and event; the 'returns': of command; the 'base': of type and union) must resolve to an appropriate subset of metatypes declared by the current qapi parse; this includes recursing into each member of a data dictionary. Dealing with '**' and nested anonymous structs will be done in later patches. Update the testsuite to match improved output. 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 testsEric Blake2015-05-0560-0/+112
| | | | | | | | | | | | | | | | | | | | | 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>
* qapi: Unify type bypass and add testsEric Blake2015-05-0512-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | For a few QMP commands, we are forced to pass an arbitrary type without tracking it properly in QAPI. Among the existing clients, this unnamed type was spelled 'dict', 'visitor', and '**'; this patch standardizes on '**', matching the documentation changes earlier in the series. Meanwhile, for the 'gen' key, we have been ignoring the value, although the schema consistently used "'no'" ('success-response' was hard-coded to checking for 'no'). But now that we can support a literal "false" in the schema, we might as well use that rather than ignoring the value or special-casing a random string. Note that these are one-way switches (use of 'gen':true is not the same as omitting 'gen'). Also, the use of '**' requires 'gen':false, but the use of 'gen':false does not mandate the use of '**'. There is no difference to the generated code. Add some tests on what we'd like to guarantee, although it will take later patches to clean up test results and actually enforce the use of a bool parameter. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Allow true, false and null in schema jsonFam Zheng2015-05-052-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | In the near term, we will use it for a sensible-looking 'gen':false inside command declarations, instead of the current ugly 'gen':'no'. In the long term, it will allow conversion from shorthand with defaults mentioned only in side-band documentation: 'data':{'*flag':'bool', '*string':'str'} into an explicit default value documentation, as in: 'data':{'flag':{'type':'bool', 'optional':true, 'default':true}, 'string':{'type':'str', 'optional':true, 'default':null}} We still don't parse integer values (also necessary before we can allow explicit defaults), but that can come in a later series. Update the testsuite to match an improved error message. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Better error messages for duplicated expressionsEric Blake2015-05-0528-40/+21
| | | | | | | | | | | | | | | | | | | | | | The previous commit demonstrated that the generator overlooked duplicate expressions: - a complex type or command reusing a built-in type name - redeclaration of a type name, whether by the same or different metatype - redeclaration of a command or event - collision of a type with implicit 'Kind' enum for a union - collision with an implicit MAX enum constant Since the c_type() function in the generator treats all names as being in the same namespace, this patch adds a global array to track all known names and their source, to prevent collisions before it can cause further problems. While valid .json files won't trigger any of these cases, we might as well be nicer to developers that make a typo while trying to add new QAPI code. 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 tests of redefined expressionsEric Blake2015-05-0524-0/+43
| | | | | | | | | | | | | | Demonstrate that the qapi generator doesn't deal very well with redefined expressions. At the parse level, they are silently accepted; and while the testsuite just stops at parsing, I've further tested that many of them cause generator crashes or invalid C code if they were appended to qapi-schema-test.json. A later patch will tighten things up and adjust the testsuite to match. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Better error messages for bad expressionsEric Blake2015-05-0523-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit demonstrated that the generator overlooked some fairly basic broken expressions: - missing metataype - metatype key has a non-string value - unknown key in relation to the metatype - conflicting metatype (this patch treats the second metatype as an unknown key of the first key visited, which is not necessarily the first key the user typed) Add check_keys to cover these situations, and update testcases to match. A couple other tests (enum-missing-data, indented-expr) had to change since the validation added here occurs so early. Conversely, changes to ident-with-escape results show that we still have problems where our handling of escape sequences differs from true JSON, which will matter down the road if we allow arbitrary default string values for optional parameters (but for now is not too bad, as we currently can avoid unicode escaping as we don't need to represent anything beyond C identifier material). While valid .json files won't trigger any of these cases, we might as well be nicer to developers that make a typo while trying to add new QAPI code. 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 expr testsEric Blake2015-05-0544-0/+67
| | | | | | | | | | | | | | | | | | | Demonstrate that the qapi generator doesn't deal well with expressions that aren't up to par. Later patches will improve the expected results as the generator is made stricter. Only a few of the the added tests actually behave sanely at rejecting obvious problems or demonstrating success. Note that in some cases, we reject bad QAPI merely because our pseudo-JSON parser does not yet know how to parse numbers. This series does not address that, but when a later series adds support for numeric defaults of integer fields, the testsuite will ensure that we don't lose the error (and hopefully that the error message quality is improved). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Use 'alternate' to replace anonymous unionEric Blake2015-05-0520-41/+32
| | | | | | | | | | | | | Previous patches have led up to the point where I create the new meta-type "'alternate':'Foo'". See the previous patches for documentation; I intentionally split as much work into earlier patches to minimize the size of this patch, but a lot of it is churn due to testsuite fallout after updating to the new type. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Rename anonymous union type in testEric Blake2015-05-052-3/+3
| | | | | | | | | | Reduce churn in the future patch that replaces anonymous unions with a new metatype 'alternate' by changing 'AnonUnion' to 'Alternate'. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Segregate anonymous unions into alternates in generatorEric Blake2015-05-052-2/+2
| | | | | | | | | | | | | | | | | | Special-casing 'discriminator == {}' for handling anonymous unions is getting awkward; since this particular type is not always a dictionary on the wire, it is easier to treat it as a completely different class of type, "alternate", so that if a type is listed in the union_types array, we know it is not an anonymous union. This patch just further segregates union handling, to make sure that anonymous unions are not stored in union_types, and splitting up check_union() into separate functions. A future patch will change the qapi grammar, and having the segregation already in place will make it easier to deal with the distinct meta-type. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Tighten checking of unionsEric Blake2015-05-0546-75/+36
| | | | | | | | | | | | | | | | | | | | Previous commits demonstrated that the generator had several flaws with less-than-perfect unions: - a simple union that listed the same branch twice (or two variant names that map to the same C enumerator, including the implicit MAX sentinel) ended up generating invalid C code - an anonymous union that listed two branches with the same qtype ended up generating invalid C code - the generator crashed on anonymous union attempts to use an array type - the generator was silently ignoring a base type for anonymous unions - the generator allowed unknown types or nested anonymous unions as a branch in an anonymous union Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Forbid base without discriminator in unionsEric Blake2015-05-056-16/+3
| | | | | | | | | | | | | | | | | None of the existing QMP or QGA interfaces uses a union with a base type but no discriminator; it is easier to avoid this in the generator to save room for other future extensions more likely to be useful. An earlier commit added a union-base-no-discriminator test to ensure that we eventually give a decent error message; likewise, removing UserDefUnion outright is okay, because we moved all the tests we wish to keep into the tests of the simple union UserDefNativeListUnion in the previous commit. Now is the time to actually forbid simple union with base, and remove the last vestiges from the testsuite. 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 union testsEric Blake2015-05-0588-6/+314
| | | | | | | | | | | | | | | | | | | | | | | | | Demonstrate that the qapi generator doesn't deal well with unions that aren't up to par. Later patches will update the expected reseults as the generator is made stricter. A few tests work as planned, but most show poor or missing error messages. Of particular note, qapi-code-gen.txt documents 'base' only for flat unions, but the tests here demonstrate that we currently allow a 'base' to a simple union, although it is exercised only in the testsuite. Later patches will remove this undocumented feature, to give us more flexibility in adding other future extensions to union types. For example, one possible extension is the idea of a type-safe simple enum, where added fields tie the discriminator to a user-defined enum type rather than creating an implicit enum from the names in 'data'. But adding such safety on top of a simple enum with a base type could look ambiguous with a flat enum; besides, the documentation also mentions how any simple union can be represented by an equivalent flat union. So it will be simpler to just outlaw support for something we aren't using. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Better error messages for bad enumsEric Blake2015-05-0518-27/+14
| | | | | | | | | | | | | | | | | | | | | | | | | The previous commit demonstrated that the generator had several flaws with less-than-perfect enums: - an enum that listed the same string twice (or two variant strings that map to the same C enumerator) ended up generating an invalid C enum - because the generator adds a _MAX terminator to each enum, the use of an enum member 'max' can also cause this clash - if an enum omits 'data', the generator left a python stack trace rather than a graceful message - an enum that used a non-array 'data' was silently accepted by the parser - an enum that used non-string members in the 'data' member was silently accepted by the parser Add check_enum to cover these situations, and update testcases to match. While valid .json files won't trigger any of these cases, we might as well be nicer to developers that make a typo while trying to add new QAPI code. 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 enum testsEric Blake2015-05-0536-0/+61
| | | | | | | | | | Demonstrate that the qapi generator doesn't deal well with enums that aren't up to par. Later patches will update the expected results as the generator is made stricter. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Fix generation of 'size' builtin typeEric Blake2015-05-052-2/+3
| | | | | | | | | We were missing the 'size' builtin type (which means that QAPI using [ 'size' ] would fail to compile). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* tests: add QMP input visitor test for unions with no discriminatorMichael Roth2014-09-262-0/+13
| | | | | | | | | | | | | | This is more of an exercise of the dealloc visitor, where it may erroneously use an uninitialized discriminator field as indication that union fields corresponding to that discriminator field/type are present, which can lead to attempts to free random chunks of heap memory. Cc: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
OpenPOWER on IntegriCloud