First real chunk of the compiler, the parser and its associated code generation
xtask/: This is where all of the xtask stuff lives, run cargo xtask to see a help menu. It deals with setup and code generation at the moment but will probably be extended in the future. Useful commands are cargo xtask setup (setup and initialize your local repository), cargo xtask codegen (run code generation) and cargo xtask codegen check (check that the generated code currently within the repo is up-to-date)
crates/ddlog-syntax/: The syntax tree and parser for the compiler and lsp
ast/: The generated concrete syntax tree definitions along with some utilities for them, mostly generated code
parser/: The actual parsing code, the notable files being expr.rs, stmt.rs and item.rs. The rest is pretty much just plumbing and stuff to make things nicer to work with
syntax_kind/: The syntax kind definitions, mostly generated code
validation/: The parser is overly flexible (on purpose), so we parse more things than are actually syntactically valid. This is what the validation module is for, it's a series of passes over the produced ast that produces nice diagnostics for syntax errors. The idea behind being overly generous with what can be parsed is that it works in favor of error recovery and produces better, more helpful errors, which leads to a better user experience. It also means that we don't have to stop entirely if the user adds, for example, an extra comma between function arguments. Instead, we can continue further stages of the pipeline to try and give any further errors there instead of being halted at the invalid syntax
tests/: Test suite for the parsing and validation machinery. Tests are written inline within the actual code and then put into files by cargo xtask codegen so that they can be run, this is where the generated files live. tests/filetests.rs is the only "real" file here, the rest are just generated files containing the source text of a test and the expected output it'll produce
First real chunk of the compiler, the parser and its associated code generation
xtask/: This is where all of the xtask stuff lives, runcargo xtaskto see a help menu. It deals with setup and code generation at the moment but will probably be extended in the future. Useful commands arecargo xtask setup(setup and initialize your local repository),cargo xtask codegen(run code generation) andcargo xtask codegen check(check that the generated code currently within the repo is up-to-date)crates/ddlog-syntax/: The syntax tree and parser for the compiler and lspast/: The generated concrete syntax tree definitions along with some utilities for them, mostly generated codeparser/: The actual parsing code, the notable files beingexpr.rs,stmt.rsanditem.rs. The rest is pretty much just plumbing and stuff to make things nicer to work withsyntax_kind/: The syntax kind definitions, mostly generated codevalidation/: The parser is overly flexible (on purpose), so we parse more things than are actually syntactically valid. This is what the validation module is for, it's a series of passes over the produced ast that produces nice diagnostics for syntax errors. The idea behind being overly generous with what can be parsed is that it works in favor of error recovery and produces better, more helpful errors, which leads to a better user experience. It also means that we don't have to stop entirely if the user adds, for example, an extra comma between function arguments. Instead, we can continue further stages of the pipeline to try and give any further errors there instead of being halted at the invalid syntaxtests/: Test suite for the parsing and validation machinery. Tests are written inline within the actual code and then put into files bycargo xtask codegenso that they can be run, this is where the generated files live.tests/filetests.rsis the only "real" file here, the rest are just generated files containing the source text of a test and the expected output it'll produce