Initial commit for a cpp-peglib based parser and untyped AST gen

[sylvanc]

This uses cpp-peglib to generate a packrat PEG for a grammar defined
in a text file, and then does some very basic AST manipulation. It
sets up scopes and symbol tables, and does a bit of fixity analysis.
The intention is to use this for a very slim parser front-end that
goes to MLIR before any serious heavy lifting is done. No tests are
included in the initial commit, as the grammar.peg is preliminary.Z

[mjp41]

Can you use

https://github.com/yhirose/cpp-peglib.git

as the submodule reference, rather than an ssh based one.

[rengolin]

Quick overall comment, there are a number of assumptions (make_shared onto nullptr, fields were set before use) that could segfault without errors.

I think adding user errors for those is wrong, because it's not a user error, so assert would be the right level, I think. CMake has release builds with assert, which are good for testing that kind of thing.

[rengolin]

The lack of tests should be fine, given the state of the grammar and the prototype. I think this can be the next task after merge, to go through the list of tests we already have and make sure they have the syntax we want and change the parser/tests to match it.

This will be a long process, with a lot of discussion, and can happen in parallel with other work (ex. the MLIR bridge, runtime libraries).

[rengolin]

Initial list of files from the testsuite (marked as compile-pass) that this front-end parses into AST:

./resolution/compile-pass/circular.verona
./resolution/compile-pass/interleaved.verona
./reachability/compile-pass/visit-variable-renaming-type.verona
./reachability/compile-pass/visit-receiver.verona
./features/compile-pass/library/sibling.verona
./features/compile-pass/cell.verona
./typechecking/compile-pass/field-write.verona

None of the run-pass parses.

It seems most (if not all) errors are on class declaration.

This is just a comment, for future reference, doesn't preclude merging the code as is.

[rengolin]

A few more inline comments, but I'm done. I think this is a straight forward implementation of a parser that despite being in a raw state is actually a good start for what we want to do with it. If we had a fully tested parser now, we'd have to keep changing tests to accommodate the evolving language.

Right now, it's simple enough that will be easy to change either parser or examples to suite our design process, and that's the best of both worlds. So, to me, it looks good to merge. Any comments above could be implemented post-merge without needing to withhold this patch.

[mjp41]

Good start for this.

[mjp41]

Actually can we remove it from building in CI. I don't really want failed CI ever on master.