This is a simple extension of GenericLexer, and is used in more than
just LibXML, so let's move it into AK.
The move also resolves a FIXME, which is removed in this commit.
Due to the way expression parser is written, we need to resolve the
ambiguity between member access operators and dots used for punctuation
during lexing. The lexer uses a (totally bulletproof) heuristic to do
that: whenever '.' is followed by ' ' or '\n', it is considered a dot
and member access otherwise. While it works fine for prettified test
cases, non-prettified files often lack enter after a trailing dot
character. Since MemberAccess will always be invalid at that position,
explicitly treat trailing dot as a part of punctuation.
We cannot handle them normally since we need text between parenthesis to
be a valid expression. As a workaround, we now push an artificial value
to stack to act as an argument (it'll be later removed during function
call canonicalization).
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.
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.
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.
