I got fed up with looking at error messages that tell me "VERIFICATION
FAILED: !is_error()". So this commit introduces DiagnosticEngine class
whose purpose is to accumulate and print more user-friendly errors.
For some reason I was afraid to add trivial accessors to classes
in earlier PRs, so we now have dozens of classes with public fields. I'm
not exactly looking forward to refactoring them all at once but I'll
do so gradually.
This commit introduces NamedVariableDeclaration and
SSAVariableDeclaration and allows storing both of them in Variable node.
Also, it adds additional structures in FunctionDefinition and
BasicBlock, which will be used to store SSA form related information.
We assume that variable shadowing is impossible, so then there is no
reason to keep distinct Declaration and Assignment operators after
ReferenceResolvingPass.
In a bunch of cases, this actually ends up simplifying the code as
to_number will handle something such as:
```
Optional<I> opt;
if constexpr (IsSigned<I>)
opt = view.to_int<I>();
else
opt = view.to_uint<I>();
```
For us.
The main goal here however is to have a single generic number conversion
API between all of the String classes.
This will effectively allow us to use C++ code as an input for the
compiler. This would be useful for testing, since otherwise we would
have had to specify tests as a spec-like XML, which is not exactly the
most developer-friendly experience.
It simplifies ladders of BinaryOperators nodes in the function call
arguments into nice and neat FunctionCall node. Ladders initially appear
since I do not want to complicate expression parser, so it interprets
`f(a, b, c, d)` as `f "function_call_operator" (a, (b, (c, d))))`.
This class stores a non-owning raw pointer to a member of `Node`, so
extra care is needed to ensure that referenced `Node`s will be alive
by the time `NodeSubtreePointer` is used. Since we only need to use this
class while traversing AST in `RecursiveASTVisitor`, access to class
methods can be restricted using `Badge<RecursiveASTVisitor>`.
Currently, they are not extremely useful, but the plan is to store
all function-local state in JSSpecCompiler::Function and all
"translation unit" state in ExecutionContext.
