Skip to content
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

Merged
merged 4 commits into from
Sep 11, 2024

Conversation

kazimuth
Copy link
Contributor

@kazimuth kazimuth commented Sep 3, 2024

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.

Copy link
Contributor

@cloutiertyler cloutiertyler left a 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_))
Copy link
Member

@RReverser RReverser Sep 5, 2024

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.

Copy link
Contributor Author

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.

Copy link
Member

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".

Copy link
Contributor Author

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. ;-;

Copy link
Member

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? 😅

Copy link
Contributor Author

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>,
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 TypeDefs in ModuleDef, so you'll have it available.

@coolreader18
Copy link
Collaborator

coolreader18 commented Sep 5, 2024

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.

crates/sats/src/proptest.rs Outdated Show resolved Hide resolved
crates/schema/src/type_for_generate.rs Outdated Show resolved Hide resolved

/// Cycles passing through definitions are allowed.
/// This function is called after all definitions have been processed.
fn mark_allowed_cycles(&mut self) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use review

@bfops bfops added the release-any To be landed in any release window label Sep 9, 2024
@kazimuth kazimuth force-pushed the jgilles/algebraic_type_for_generate branch from 16d16b4 to f88641d Compare September 10, 2024 17:28
@@ -296,6 +296,37 @@ pub struct RawScheduleDefV9 {
pub reducer_name: RawIdentifier,
}

/// A constraint definition attached to a table.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also important

@kazimuth kazimuth enabled auto-merge September 10, 2024 20:17
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
@kazimuth kazimuth disabled auto-merge September 11, 2024 16:09
@kazimuth kazimuth force-pushed the jgilles/algebraic_type_for_generate branch from 35c7cef to 52ec634 Compare September 11, 2024 16:09
@kazimuth kazimuth added this pull request to the merge queue Sep 11, 2024
@kazimuth kazimuth removed this pull request from the merge queue due to a manual request Sep 11, 2024
@kazimuth kazimuth added this pull request to the merge queue Sep 11, 2024
@cloutiertyler cloutiertyler removed this pull request from the merge queue due to a manual request Sep 11, 2024
@cloutiertyler cloutiertyler merged commit f3e3d92 into master Sep 11, 2024
8 checks passed
@kazimuth kazimuth deleted the jgilles/algebraic_type_for_generate branch September 11, 2024 20:44
This was referenced Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-any To be landed in any release window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants