aboutsummaryrefslogtreecommitdiff
path: root/scripts/qapi
AgeCommit message (Collapse)AuthorFilesLines
2021-09-08qapi: Fix bogus error for 'if': { 'not': '' }Markus Armbruster1-8/+13
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210908045428.2689093-6-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [check_infix()'s type hint fixed]
2021-09-08qapi: Bury some unused code in class IndentationMarkus Armbruster1-6/+1
.__int__() has never been used. Drop it. .decrease() raises ArithmeticError when asked to decrease indentation level below zero. Nothing catches it. It's a programming error. Dumb down to assert. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210908045428.2689093-4-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-08qapi: Drop Indentation.__bool__()Markus Armbruster1-6/+3
Intentation.__bool__() is not worth its keep: it has just one user, which can just as well check .__str__() instead. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210908045428.2689093-3-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-08qapi: Fix a botched type annotationMarkus Armbruster1-1/+2
Mypy is unhappy: $ mypy --config-file=scripts/qapi/mypy.ini `git-ls-files scripts/qapi/\*py` scripts/qapi/common.py:208: error: Function is missing a return type annotation scripts/qapi/common.py:227: error: Returning Any from function declared to return "str" Messed up in commit ccea6a8637 "qapi: Factor common recursion out of cgen_ifcond(), docgen_ifcond()". Tidy up. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210908045428.2689093-2-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Tweak error messages for unknown / conflicting 'if' keysMarkus Armbruster1-4/+3
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-13-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Tweak error messages for missing / conflicting meta-typeMarkus Armbruster1-14/+9
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-12-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Use re.fullmatch() where appropriateMarkus Armbruster1-1/+1
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-10-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Use "not COND" instead of "!COND" for generated documentationMarkus Armbruster1-1/+1
Generated documentation uses operators "and", "or", and "!". Change the latter to "not". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-9-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Avoid redundant parens in code generated for conditionalsMarkus Armbruster1-4/+6
Commit 6cc2e4817f "qapi: introduce QAPISchemaIfCond.cgen()" caused a minor regression: redundant parenthesis. Subsequent commits eliminated of many of them, but not all. Get rid of the rest now. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-8-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Factor common recursion out of cgen_ifcond(), docgen_ifcond()Markus Armbruster1-20/+25
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-7-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Fix C code generation for 'if'Markus Armbruster1-2/+2
When commit 5d83b9a130 "qapi: replace if condition list with dict {'all': [...]}" made cgen_ifcond() and docgen_ifcond() recursive, it messed up parenthesises in the former, and got them right in the latter, as the previous commit demonstrates. To fix, adopt the latter's working code for the former. This generates the correct code from the previous commit's commit message. Fixes: 5d83b9a130690f879d5f33e991beabe69cb88bc8 Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-6-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Simplify how QAPISchemaIfCond represents "no condition"Markus Armbruster2-3/+3
None works fine, there is no need to replace it by {} in .__init__(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-3-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-09-03qapi: Simplify QAPISchemaIfCond's interface for generating CMarkus Armbruster5-38/+31
QAPISchemaIfCond.cgen() is only ever used like gen_if(ifcond.cgen()) and gen_endif(ifcond.cgen()) Simplify to ifcond.gen_if() and ifcond.gen_endif() Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210831123809.1107782-2-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [Import statements tidied up with isort]
2021-08-26qapi: make 'if' condition strings simple identifiersMarc-André Lureau2-3/+3
Change the 'if' condition strings to be C-agnostic. It will accept '[A-Z][A-Z0-9_]*' identifiers. This allows to express configuration conditions in other languages (Rust or Python for ex) or other more suitable forms. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: John Snow <jsnow@redhat.com> Message-Id: <20210804083105.97531-11-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Rebased with semantic conflict in redefined-event.json] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: add 'not' condition operationMarc-André Lureau2-2/+9
For the sake of completeness, introduce the 'not' condition. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-10-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Long line broken in tests/qapi-schema/qapi-schema-test.json] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: add 'any' conditionMarc-André Lureau2-5/+5
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-8-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: replace if condition list with dict {'all': [...]}Marc-André Lureau3-31/+54
Replace the simple list sugar form with a recursive structure that will accept other operators in the following commits (all, any or not). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-7-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Accidental code motion undone. Degenerate :forms: comment dropped. Helper _check_if() moved. Error messages tweaked. ui.json updated. Accidental changes to qapi-schema-test.json dropped.] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapidoc: introduce QAPISchemaIfCond.docgen()Marc-André Lureau2-1/+16
Instead of building the condition documentation from a list of string, use the result generated from QAPISchemaIfCond.docgen(). This changes the generated documentation from: - COND1, COND2... (where COND1, COND2 are Literal nodes, and ',' is Text) to: - COND1 and COND2 (the whole string as a Literal node) This will allow us to generate more complex conditions in the following patches, such as "(COND1 and COND2) or COND3". Adding back the differentiated formatting is left to the wish list. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-6-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [TODO comment added] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: introduce QAPISchemaIfCond.cgen()Marc-André Lureau6-34/+46
Instead of building prepocessor conditions from a list of string, use the result generated from QAPISchemaIfCond.cgen() and hide the implementation details. Note: this patch introduces a minor regression, generating a redundant pair of parenthesis. This is mostly fixed in a later patch in this series ("qapi: replace if condition list with dict [..]") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-5-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Commit message tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: add QAPISchemaIfCond.is_present()Marc-André Lureau2-4/+7
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210804083105.97531-4-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: wrap Sequence[str] in an objectMarc-André Lureau7-76/+93
Mechanical change, except for a new assertion in QAPISchemaEntity.ifcond(). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210804083105.97531-3-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Rebased with obvious conflicts, commit message adjusted] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-08-26qapi: Fix crash on redefinition with a different conditionMarkus Armbruster1-11/+11
QAPISchema._make_implicit_object_type() asserts that when an implicit object type is used multiple times, @ifcond is the same for all uses. It will be for legitimate uses, i.e. simple union branch wrapper types. A comment explains this. The assertion fails when a command or event is redefined with a different condition. The redefinition is an error, but it's flagged only later. Fixing the assertion would complicate matters further. Not worthwhile, drop it instead. We really need to get rid of simple unions. Tweak test case redefined-event to cover redefinition with a different condition. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210806120510.2367124-1-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2021-07-15qapi: Fix crash on missing enum member nameMarkus Armbruster1-1/+1
New test case enum-dict-no-name.json crashes: $ python3 scripts/qapi-gen.py tests/qapi-schema/enum-dict-no-name.json Traceback (most recent call last): [...] File "/work/armbru/qemu/scripts/qapi/expr.py", line 458, in check_enum member_name = member['name'] KeyError: 'name' Root cause: we try to retrieve member 'name' before we check for missing members. With that fixed, we get the expected error "'data' member misses key 'name'". Fixes: 0825f62c842f2c07c5471391c6d7fd3f4fe83732 Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210616072121.626431-1-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2021-05-20qapi/parser: add docstringsJohn Snow1-0/+69
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-16-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Doc string spacing tweaked slightly] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: allow 'ch' variable nameJohn Snow1-0/+1
We can have a two-letter variable name, as a treat. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-15-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Remove superfluous list comprehensionJohn Snow1-1/+1
A generator suffices (and quiets a pylint warning). Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-14-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: add type hint annotationsJohn Snow1-20/+38
Annotations do not change runtime behavior. This commit *only* adds annotations. (Annotations for QAPIDoc are in a forthcoming commit.) Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-13-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Rework _check_pragma_list_of_str as a TypeGuardJohn Snow1-14/+16
TypeGuards wont exist in Python proper until 3.10. Ah well. We can hack up our own by declaring this function to return the type we claim it checks for and using this to safely downcast object -> List[str]. In so doing, I bring this function under _pragma so it can use the 'info' object in its closure. Having done this, _pragma also now no longer needs to take a 'self' parameter, so drop it. To help with line-length, and with the context evident from its new scope, rename the function to the shorter check_list_str(). Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-12-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Fix token membership tests when token can be NoneJohn Snow1-2/+3
When the token can be None (EOF), we can't use 'x in "abc"' style membership tests to group types of tokens together, because 'None in "abc"' is a TypeError. Easy enough to fix. (Use a tuple: It's neither a static typing error nor a runtime error to check for None in Tuple[str, ...]) Add tests to prevent a regression. (Note: they cannot be added prior to this fix, as the unhandled stack trace will not match test output in the CI system.) Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-11-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi: add must_match helperJohn Snow3-11/+16
Mypy cannot generally understand that these regex functions cannot possibly fail. Add a "must_match" helper that makes this clear for mypy. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-10-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Use @staticmethod where appropriateJohn Snow1-2/+4
No self, no thank you! (Quiets pylint warnings.) Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-9-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: assert object keys are stringsJohn Snow1-0/+2
The single quote token implies the value is a string. Assert this to be the case, to allow us to write an accurate return type for get_members. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-8-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: enforce all top-level expressions must be dict in _parse()John Snow1-6/+8
Instead of using get_expr nested=False, allow get_expr to always return any expression. In exchange, add a new error message to the top-level parser that explains the semantic error: Top-level expressions must always be JSON objects. This helps mypy understand the rest of this function which assumes that get_expr did indeed return a dict. The exception type changes from QAPIParseError to QAPISemError as a result, and the error message in two tests now changes. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-7-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Assert lexer value is a stringJohn Snow1-0/+1
The type checker can't narrow the type of the token value to string, because it's only loosely correlated with the return token. We know that a token of '#' should always have a "str" value. Add an assertion. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-6-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: factor parsing routine into methodJohn Snow1-12/+28
For the sake of keeping __init__ smaller (and treating it more like a gallery of what state variables we can expect to see), put the actual parsing action into a parse method. It remains invoked from the init method to reduce churn. To accomplish this, @previously_included becomes the private data member ._included, and the filename is stashed as ._fname. Add any missing declarations to the init method, and group them by function so they can be understood quickly at a glance. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-5-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/source: Remove line number from QAPISourceInfo initializerJohn Snow2-8/+4
With the QAPISourceInfo(None, None, None) construct gone, there's no longer any reason to have to specify that a file starts on the first line. Remove it from the initializer and default it to 1. Remove the last vestiges where we check for 'line' being unset, that can't happen, now. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-4-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-05-20qapi/parser: Don't try to handle file errorsJohn Snow3-14/+18
Fixes: f5d4361cda Fixes: 52a474180a Fixes: 46f49468c6 Remove the try/except block that handles file-opening errors in QAPISchemaParser.__init__() and add one each to QAPISchemaParser._include() and QAPISchema.__init__() respectively. This simultaneously fixes the typing of info.fname (f5d4361cda), A static typing violation in test-qapi (46f49468c6), and a regression of an error message (52a474180a). The short-ish version of what motivates this patch is: - It's hard to write a good error message in the init method, because we need to determine the context of our caller to do so. It's easier to just let the caller write the message. - We don't want to allow QAPISourceInfo(None, None, None) to exist. The typing introduced by commit f5d4361cda types the 'fname' field as (non-optional) str, which was premature until the removal of this construct. - Errors made using such an object are currently incorrect (since 52a474180a) - It's not technically a semantic error if we cannot open the schema. - There are various typing constraints that make mixing these two cases undesirable for a single special case. - test-qapi's code handling an fname of 'None' is now dead, drop it. Additionally, Not all QAPIError objects have an 'info' field (since 46f49468), so deleting this stanza corrects a typing oversight in test-qapi introduced by that commit. Other considerations: - open() is moved to a 'with' block to ensure file pointers are cleaned up deterministically. - Python 3.3 deprecated IOError and made it a synonym for OSError. Avoid the misleading perception these exception handlers are narrower than they really are. The long version: The error message here is incorrect (since commit 52a474180a): > python3 qapi-gen.py 'fake.json' qapi-gen.py: qapi-gen.py: can't read schema file 'fake.json': No such file or directory In pursuing it, we find that QAPISourceInfo has a special accommodation for when there's no filename. Meanwhile, the intent when QAPISourceInfo was typed (f5d4361cda) was non-optional 'str'. This usage was overlooked. To remove this, I'd want to avoid having a "fake" QAPISourceInfo object. I also don't want to explicitly begin accommodating QAPISourceInfo itself being None, because we actually want to eventually prove that this can never happen -- We don't want to confuse "The file isn't open yet" with "This error stems from a definition that wasn't defined in any file". (An earlier series tried to create a dummy info object, but it was tough to prove in review that it worked correctly without creating new regressions. This patch avoids that distraction. We would like to first prove that we never raise QAPISemError for any built-in object before we add "special" info objects. We aren't ready to do that yet.) So, which way out of the labyrinth? Here's one way: Don't try to handle errors at a level with "mixed" semantic contexts; i.e. don't mix inclusion errors (should report a source line where the include was triggered) and command line errors (where we specified a file we couldn't read). Remove the error handling from the initializer of the parser. Pythonic! Now it's the caller's job to figure out what to do about it. Handle the error in QAPISchemaParser._include() instead, where we can write a targeted error message where we are guaranteed to have an 'info' context to report with. The root level error can similarly move to QAPISchema.__init__(), where we know we'll never have an info context to report with, so we use a more abstract error type. Now the error looks sensible again: > python3 qapi-gen.py 'fake.json' qapi-gen.py: can't read schema file 'fake.json': No such file or directory With these error cases separated, QAPISourceInfo can be solidified as never having placeholder arguments that violate our desired types. Clean up test-qapi along similar lines. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210519183951.3946870-2-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error.py: enable mypy checksJohn Snow1-5/+0
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-9-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error: Add type hintsJohn Snow1-2/+9
No functional change. Note: QAPISourceError's info parameter is Optional[] because schema.py treats the info property of its various classes as Optional to accommodate built-in types, which have no source. See prior commit 'qapi/error: assert QAPISourceInfo is not None'. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-8-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error.py: enable pylint checksJohn Snow1-2/+1
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-7-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error.py: move QAPIParseError to parser.pyJohn Snow2-15/+21
Keeping it in error.py will create some cyclic import problems when we add types to the QAPISchemaParser. Callers don't need to know the details of QAPIParseError unless they are parsing or dealing directly with the parser, so this won't create any harsh new requirements for callers in the general case. Update error.py with a little docstring that gives a nod to where the error may now be found. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-6-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error: assert QAPISourceInfo is not NoneJohn Snow1-0/+1
Built-in stuff is not parsed from a source file, and therefore have no QAPISourceInfo. If such None info was used for reporting an error, built-in stuff would be broken. Programming error. Instead of reporting a confusing error with bogus source location then, we better crash. We currently crash only if self.col was set. Assert that self.info is not None in order to crash reliably. We can not yet change the type of the initializer to prove this cannot happen at static analysis time before the remainder of the code is fully typed. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-5-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error: Make QAPISourceError 'col' parameter optionalJohn Snow2-7/+4
It's already treated as optional, with one direct caller and some subclass callers passing 'None'. Make it officially optional, which requires moving the position of the argument to come after all required parameters. QAPISemError becomes functionally identical to QAPISourceError. Keep the name to preserve its semantic meaning and avoid code churn, but remove the now-useless __init__ wrapper. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-4-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error: Use Python3-style super()John Snow1-1/+1
Missed in commit 2cae67bcb5 "qapi: Use super() now we have Python 3". Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210421192233.3542904-3-jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/error: Repurpose QAPIError as an abstract base exception classJohn Snow2-4/+12
Rename QAPIError to QAPISourceError, and then create a new QAPIError class that serves as the basis for all of our other custom exceptions, without specifying any class properties. This leaves QAPIError as a package-wide error class that's suitable for any current or future errors. (Right now, we don't have any errors that DON'T also want to specify a Source location, but this MAY change. In these cases, a common abstract ancestor would be desired.) Add docstrings to explain the intended function of each error class. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421192233.3542904-2-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/expr: Update authorship and copyright informationJohn Snow1-1/+2
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421182032.3521476-18-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/expr.py: Use tuples instead of lists for static dataJohn Snow1-2/+2
It is -- maybe -- possibly -- three nanoseconds faster. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20210421182032.3521476-17-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/expr.py: Add docstringsJohn Snow1-5/+251
Now with more :words:! Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421182032.3521476-16-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/expr: Only explicitly prohibit 'Kind' nor 'List' for type namesJohn Snow1-3/+3
Per list review: qapi-code-gen.txt reserves suffixes Kind and List only for type names, but the code rejects them for events and commands, too. It turns out we reject them earlier anyway: In check_name_upper() for event names, and in check_name_lower() for command names. Still, adjust the code for clarity over what precisely we are guarding against. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210421182032.3521476-15-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-04-30qapi/expr.py: enable pylint checksJohn Snow1-1/+0
Signed-off-by: John Snow <jsnow@redhat.com> Tested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20210421182032.3521476-14-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
generated by cgit v1.1 at 2025-01-30 02:23:03 +0000