-
Notifications
You must be signed in to change notification settings - Fork 664
Split client codegen out into its own crate #2593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I don't have any input here, feel free to move this one forward without me 👍 |
04044a1 to
7a75667
Compare
bfops
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, the code LGTM! As you said, if the existing tests pass and the snapshots are unchanged, this seems like it should be good.
Also TIL about git diff --color-moved.
cloutiertyler
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CODEOWNERS change LGTM
fbcac0e to
f8193f5
Compare
Description of Changes
This is something I've had a branch for for a while, and now that #2244 is merged I can open it. This makes the codeowners situation simpler, and also lets us put the codegen snapshot tests directly with the codegen crate instead of as integration tests using the Rust api of the CLI.
I moved the
Lang::{format_files,clap_value}functions off of the trait because those aren't really related to codegen, and fit better in thespacetimedb_cli::tasksmodule and inlined intoto_possible_valuerespectively.API and ABI breaking changes
Expected complexity level and risk
1: if you review with
git diff master --color-moved, you'll see that most of this is just very straightforward code movement.Testing
n/a; no new behavior and the codegen snapshot tests still pass.