Before this commit the code was wrong in 2 ways:
- if failed to iterate on children, because it iterated a range that was
effectively [begin, begin) instead of [begin, end)
- the update of the ARootNext iterator in the loop was broken, but it
was impossible to realize that since the loop was never taken
This commit fixes both these intertwined problems.
The FieldAttr::verify checking for non-complete field types was testing
for completeness too eagerly and was removed. Forbidding class type
recursion without indirection is desirable, but needs to be done less
eagerly. A new unit test to validate this via clift::ModuleOp::Verify
needs to be created to replace this one.
This change is a preparation for further decoupling of the
TypeInlineHelper from its custom dependency graph type, to try and reuse
the DependencyGraph used in ModelToHeader.
Gracefully handle the server disconnecting from a `revng graphql`
invocation. Instead of letting the stack trace be printed, output an
appropriate error message.
In the `type` function, if a file is present in the index then it should
also be checked in the bucked via a HEAD call. This allows revng to
successfully start up even if a file in the `index.yml` files has been
deleted on S3.
In some of the descriptions of Model fields/methods there are specicial
doxygen commands, such as `\sa`. These show up in python in docstrings
unescaped, causing warnings such as `SyntaxWarning: invalid escape
sequence '\s'`. In order to avoid these, replace the `\` with `\\` which
escapes to a `\`.
At the moment in C we can't emit variable declarations with inline
initialization. Not for some substantial problem, but we haven't
implemented it yet. As a result if TypeMap.at(VarDeclCall) returns a
const-qualified type we will end up generating C code that doesn't
compile, when it tries to assign a value to the variable for
initializing it separately from the declaration.
To work around this, until we don't support emission of variable
declarations with inline initialization, we have to strip away
constness.
This bug caused the expression x + (-2) < -3 to be rewritten as
(x > 2) || (x < -1), instead of (x > 2) && (x < -1).
We had tests for a very similar case, but this specific example was
triggered by having the two constant terms in the inequality with a
difference of only one.
This commit rewrites and unifies the logic for handling inequalities,
and adapts the test for checking this specific additional corner case.
Before this commit, the test was implicitly relying on control-flow
recovery and on the specific order of the then/else scopes in an
if-statement.
This commit relaxes that requirement, since it's not part of what the
test is designed to test.