Closes #13.

• [x] Comments are ignored everywhere
• [x] Enums and function arguments are parsed, if not supported
• [x] AST contains metadata like spans
• [ ] Parser creates AST from a list of tokens, not the raw string

The claw_verify crate is currently a binary, meaning it can only be tested with integration tests. (Hence the tests/ folder.) This is a proposal that the logic be abstracted into a library. A binary will then use that library, so the same functionality is exposed.

Library interface

The claw_verify crate would export both schema and definition strings, as well as some form of the Sb3Resolver.

It would also export a two functions, whose signatures would look like this:

// Added for readability
type VerifyResult = Result<(), Vec<ValidationError>>;

pub fn verify_string(script: &str) -> VerifyResult;
pub fn verify_value(script: serde_json::Value) -> VerifyResult;

Binary interface

The only thing that the binary will keep is load_file, some argument parsing, and error handling.

Woooo! This is a lot of stuff. Mainly this branch is me messing around without having to worry about CI checking my... unique code.

Basically this branch represents me going through a bunch of design changes, and ending up with Chumsky and Ariadne. I'll probably squash and merge, given how many strange commits there are.

Claw is quite early in the development process, but eventually, I want to try using benchmarks and fuzzing the code. Criterion and cargo-fuzz look promising.

Due to the current pace of development, I disabled MacOS and Windows in the CI to increase build speed. Before 0.1.0 is released, this should be turned back on to make sure it compiles. :)

https://github.com/BD103/Claw/blob/f4f137d8f47527613858f1b409c23d00adb2aae9/.github/workflows/ci.yml#L19

There are some issues with it, including:

• Comments not accepted outside of main text
• Does not support enums and function arguments
• AST does not contain metadata (like spans) necessary for #12

A rewrite is necessary. I propose converting from text to a Token enum, and then from that to AST.

Ariadne is a really nice crate for pretty error handling. It works hand-in-hand with Chumsky, which is our parser combinator in claw_parser. I would like to use it for all steps of the generation process, but it would require a few changes.

claw_driver abstraction

The driver would need to abstract core logic into a separate function that returns a Result<SB3, ariadne::Report>. This would allow all functions that it call to use the ? syntax for forwarding errors.

It may also be a good idea to convert claw_driver to a library, then create a main claw binary crate like Rustc does.

claw_parse AST with spans

The AST would need to be updated to include spans of all items, so that claw_ir can generate Reports with this information. Other info may also need to be included.

claw_ir returning Report

The claw_ir crate is still in heavy development, but the main create_ir function (or whatever name we will be using) will need to return Result<IR, Report>.

Optional: claw_verify using Report too

If claw_verify used Report, it would make error handling a lot nicer. This would help fix lifetime issues that ValidationError has.

claw_driver should include the ability to track how long it takes to compile a project, as well as how long each stage takes. This will be good for profiling to ensure speeds do not decrease. The Instant struct seems like a logical choice, though there may be other solutions.

• [x] #3
• [ ] New parsing system
  • [ ] Lexer
  • [ ] Parser
  • [ ] Update MSRV to 1.65.0
• [ ] Create intermediate representation for optimizations and easy transformation to schema
  • [ ] HIR
  • [ ] Query system
    • [ ] Optimizations setup
    • [ ] Error checking setup
• [ ] Make standard library
  • [ ] Macro for generating enum
  • [ ] Actually put in all the blocks
  • [ ] Shared types for enums, type system, etc.
• [ ] Convert schema to zip file in claw_driver
• [x] Website
  • [x] Book
  • [x] Rustdoc

Optional

• [x] #6
• [ ] Use Clap for CLI argument parsing
• [ ] #10
• [ ] ~#12~
• [ ] READMEs filled out, example folder documented, Cargo.toml finalized