-
Notifications
You must be signed in to change notification settings - Fork 109
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
Add schema::type_for_generate, update validation to use it #1661
Conversation
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.
These changes make sense to me in light of our discussion yesterday.
.and_then(|def| { | ||
if def == &AlgebraicType::Ref(ref_) { | ||
// Self-reference. | ||
Err(TypeRefError::RecursiveTypeRef(ref_)) |
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.
So this now prohibits recursive types altogether? Can we please keep them?
I currently can autogenerate C# AlgebraicType structure with all its children types directly from Rust with no issues, despite it being recursive. I'm already making use of this in ModuleDef autogen in #1670, and I'd like to use it more in the future.
If we error out on recursive types, then AlgebraicType as well as anything that depends on it - which includes ModuleDef - will error out and won't codegen anymore.
I think instead of an error we should have AlgebraicTypeUse::Ref { ref_, is_recursive }
variant so that langs that need to explicitly box the reference (only Rust among langs we currently support), have boolean tag to know that they need to do so, whereas others that already keep all the objects on the heap, can deal with it as a normal reference.
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.
Ah, I thought we didn't support recursive types in modules though. Does the code generation for that pass through this, like are you using the module codegen to generate those? I'm happy to add that tag if so.
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.
Does the code generation for that pass through this, like are you using the module codegen to generate those?
Yeah, since we don't have any other codegen, we use regular spacetime generate
for ClientApi and for this new ModuleDef and then delete files we're not interested in heh.
Someday we might clean it up, but I imagine the basic codegen pipeline is still going to be shared between modules and "just types".
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.
Cool, I'll fix that then.
Ugh now I need to actually handle cycles though. ;-;
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.
Luckily, you use Arc
so it should be as easy as downgrading it all to sync::Weak
... maybe? hopefully? 😅
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.
The cycles all pass through AlgebraicTypeRef
so no need for that even.
/// Chains of `AlgebraicTypeRef`s in the original `Typespace` are contracted to point to their ending `AlgebraicTypeDef`. | ||
#[derive(Debug, Clone)] | ||
pub struct TypespaceForGenerate { | ||
defs: HashMap<AlgebraicTypeRef, AlgebraicTypeDef>, |
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.
Could we also provide fully resolved type names here?
It would be nice not to have to worry about #[sats(name)]
, --namespace
and so on in each generator, and instead just have something akin to your ScopedTypeName
prepared and ready to be used for codegen.
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.
The relevant ScopedTypeNames are stored in the containing ModuleDef, I can add a helper accessor, or just clone them in here.
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.
In particular, you should be looking things up in here based on the TypeDef
s in ModuleDef
, so you'll have it available.
In #1675 I added some utilities to ModuleDef that make it easier/possible to do codegen - would it be ok to add those here? Maybe I'll make a PR into this branch. |
f2fe780
to
0981bb1
Compare
|
||
/// Cycles passing through definitions are allowed. | ||
/// This function is called after all definitions have been processed. | ||
fn mark_allowed_cycles(&mut self) { |
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.
This could use review
16d16b4
to
f88641d
Compare
@@ -296,6 +296,37 @@ pub struct RawScheduleDefV9 { | |||
pub reducer_name: RawIdentifier, | |||
} | |||
|
|||
/// A constraint definition attached to a table. |
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.
This is also important
minor bug in the tests in the process Add utilities to ModuleDef for easier ues for codegen (#1678) Update crates/sats/src/proptest.rs Co-authored-by: Mazdak Farrokhzad <[email protected]> Signed-off-by: james gilles <[email protected]> Move constraints around for easier future ABI evolution WIP: Allow cyclic AlgebraicTypes. Final fixes, address review comments Final comments addressed & copy editing Remove outdated comment Regenerate C# bindings autogen
35c7cef
to
52ec634
Compare
Co-authored-by: Ingvar Stepanyan <[email protected]> Signed-off-by: james gilles <[email protected]>
Description of Changes
This should significantly ease writing client codegen. @RReverser, the added types aren't serializable yet, I'll leave that to you if you'd like to do it in a further PR.
Note: I've added a requirement that all product and sum types in a ModuleDef have names for all elements, because I believe this is currently a requirement for client codegen. This can be removed if we ever figure out how to do client codegen without it.
API and ABI breaking changes
None
Expected complexity level and risk
1, the logic added here is somewhat intricate. It's tested against a good number of test cases, all of the modules in the repo, and a proptest, which gives me some confidence in it.
Testing
See the added tests in the source code.