riscv/qemu - qemu - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Markus Armbruster	f01338cce6	qapi: Speed up frontend tests "make check-qapi-schema" takes around 10s user + system time for me. With -j, it takes a bit over 3s real time. We have worse tests. It's still annoying when you work on the QAPI generator. Some 1.4s user + system time is consumed by make figuring out what to do, measured by making a target that does nothing. There's nothing I can do about that right now. But let's see what we can do about the other 8s. Almost 7s are spent running test-qapi.py for every test case, the rest normalizing and diffing test-qapi.py output. We have 190 test cases. If I downgrade to python2, it's 4.5s, but python2 is a goner. Hacking up test-qapi.py to exit(0) without doing anything makes it only marginally faster. The problem is Python startup overhead. Our configure puts -B into $(PYTHON). Running without -B is faster: 4.4s. We could improve the Makefile to run test cases only when the test case or the generator changed. But I'm after improvement in the case where the generator changed. test-qapi.py is designed to be the simplest possible building block for a shell script to do the complete job (it's actually a Makefile, not a shell script; no real difference). Python is just not meant for that. It's for bigger blocks. Move the post-processing and diffing into test-qapi.py, and make it capable of testing multiple schema files. Set executable bits while there. Running it once per test case now takes slightly longer than 8s. But running it once for all of them takes under 0.2s. Messing with the Makefile to run it only on the tests that need retesting is clearly not worth the bother. Expected error output changes because the new normalization strips off $(SRCDIR)/tests/qapi-schema/ instead of just $(SRCDIR)/. The .exit files go away, because there is no exit status to test anymore. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20191018074345.24034-5-armbru@redhat.com>	7 years ago
Markus Armbruster	eeb57c85da	qapi: Avoid redundant definition references in error messages Many error messages refer to the offending definition even though they're preceded by an "in definition" line. Rephrase them. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190927134639.4284-22-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>	7 years ago
Markus Armbruster	3f58cc29a8	qapi: Improve reporting of missing / unknown definition keys Have check_exprs() call check_keys() later, so its error messages gain an "in definition" line. Both check_keys() and check_name_is_str() check the definition's name is a string. Since check_keys() now runs after check_name_is_str() rather than before, its check is dead. Bury it. Checking values in check_keys() is unclean anyway. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20190927134639.4284-21-armbru@redhat.com>	7 years ago
Markus Armbruster	2ab218aad6	qapi: Change frontend error messages to start with lower case Starting error messages with a capital letter complicates things when text can get interpolated both at the beginning and in the middle of an error message. The next patch will do that. Switch to lower case to keep it simpler. For what it's worth, the GNU Coding Standards advise the message "should not begin with a capital letter when it follows a program name and/or file name, because that isn’t the beginning of a sentence. (The sentence conceptually starts at the beginning of the line.)" While there, avoid breaking lines containing multiple arguments in the middle of an argument. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20190927134639.4284-7-armbru@redhat.com>	7 years ago
Markus Armbruster	87c16dceca	qapi: Back out doc comments added just to please qapi.py This reverts commit 3313b61's changes to tests/qapi-schema/, except for tests/qapi-schema/doc-*. We could keep some of these doc comments to serve as positive test cases. However, they don't actually add to what we get from doc comment use in actual schemas, as we we don't test output matches expectations, and don't systematically cover doc comment features. Proper positive test coverage would be nice. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1489582656-31133-4-git-send-email-armbru@redhat.com>	9 years ago
Marc-André Lureau	3313b6124b	qapi: add qapi2texi script As the name suggests, the qapi2texi script converts JSON QAPI description into a texi file suitable for different target formats (info/man/txt/pdf/html...). It parses the following kind of blocks: Free-form: ## # = Section # == Subsection # # Some text foo with emphasis # 1. with a list # 2. like that # # And some code: # \| $ echo foo # \| -> do this # \| <- get that # ## Symbol description: ## # @symbol: # # Symbol body ditto ergo sum. Foo bar # baz ding. # # @param1: the frob to frobnicate # @param2: #optional how hard to frobnicate # # Returns: the frobnicated frob. # If frob isn't frobnicatable, GenericError. # # Since: version # Notes: notes, comments can have # - itemized list # - like this # # Example: # # -> { "execute": "quit" } # <- { "return": {} } # ## That's roughly following the following EBNF grammar: api_comment = "##\n" comment "##\n" comment = freeform_comment \| symbol_comment freeform_comment = { "# " text "\n" \| "#\n" } symbol_comment = "# @" name ":\n" { member \| tag_section \| freeform_comment } member = "# @" name ':' [ text ] "\n" freeform_comment tag_section = "# " ( "Returns:", "Since:", "Note:", "Notes:", "Example:", "Examples:" ) [ text ] "\n" freeform_comment text = free text with markup Note that the grammar is ambiguous: a line "# @foo:\n" can be parsed both as freeform_comment and as symbol_comment. The actual parser recognizes symbol_comment. See docs/qapi-code-gen.txt for more details. Deficiencies and limitations: - the generated QMP documentation includes internal types - union type support is lacking - type information is lacking in generated documentation - doc comment error message positions are imprecise, they point to the beginning of the comment. - a few minor issues, all marked TODO/FIXME in the code Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170113144135.5150-16-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [test-qapi.py tweaked to avoid trailing empty lines in .out] Signed-off-by: Markus Armbruster <armbru@redhat.com>	9 years ago
Eric Blake	0545f6b887	qapi: Better error messages for bad expressions 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>	11 years ago
Eric Blake	cf3935907b	qapi: Better error messages for bad enums 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>	11 years ago
Eric Blake	ad11dbb937	qapi: Add some enum tests 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>	11 years ago