feat(idl-gen): type resolver, generic resolver, builder

[vobradovich]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @vobradovich, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the core IDL and client code generation mechanisms. The primary goal is to enhance the robustness and maintainability of the generation process by adopting a more structured builder pattern and compile-time templating. This change streamlines how IDL files are created and how corresponding client-side Rust code is generated, leading to cleaner codebases in projects that utilize this framework.

Highlights

• IDL Generation Engine Overhaul: The IDL generation process has been completely refactored, moving from a handlebars-based templating system to a new builder pattern utilizing askama for compile-time templating. This includes the introduction of dedicated type and generic resolvers.
• Dependency Updates: The handlebars dependency has been removed, and new dependencies such as askama, quote, syn, and sails-idl-parser-v2 have been added to support the new IDL generation architecture.
• New IDL Format and Structure: All .idl files have been updated to a new format, featuring a !@sails: 0.9.2 version declaration, and a clearer separation and restructuring of program and service definitions. Type definitions are now more consistently placed within service blocks or globally.
• Client Code Generator Refinements: The client code generator has been updated to align with the new IDL structure. This includes relocating type definitions into service-specific modules, improved handling of external types like NonZeroU8 and NonZeroU32, and a more modular approach to mock generation within each service.
• Simplified Build Scripts: Example build.rs scripts have been simplified, now directly leveraging sails_rs::build_client and sails_rs::ClientBuilder for client code generation, reducing boilerplate.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a major and impressive refactoring of the sails-idl-gen crate. It replaces the old Handlebars-based IDL generation with a more robust system based on scale-info reflection, using askama for templating. This is a significant architectural improvement. The introduction of TypeResolver, GenericResolver, and Builder structures makes the code more modular and maintainable.

My review has identified one critical issue regarding commented-out tests that must be addressed. I've also pointed out several medium-severity issues, including leftover debugging statements, the use of panic! and unimplemented! macros where a Result would be more appropriate, and some placeholder names and TODO comments that should be cleaned up for better maintainability.

Overall, this is a high-quality contribution, and once the critical issue is resolved, it will be a great addition to the codebase.

[vobradovich]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a major and impressive refactoring of the sails-idl-gen crate. The old handlebars-based implementation has been replaced with a more robust and type-safe solution using askama, syn, and a new builder pattern with a sophisticated type resolver. This is a significant improvement in terms of maintainability and capability.

My review focuses on a couple of areas for improvement:

• A potential bug in how service names are inferred from file paths in sails-idl-gen.
• Some confusing commented-out code in one of the examples.

Overall, this is excellent work. The new architecture for IDL generation is much more powerful and well-structured.

[gemini-code-assist]

This commented-out code refers to a crate sails_rename which seems to be a typo and should probably be sails_idl_gen. Also, since this file seems to be for generating IDL, should this code be uncommented and fixed to use the new API? This can be confusing for users looking at the example.

[techraed]

Awesome simplification of the idl-gen was done. That's notable especially when considering struct/enum fields type names resolution.

Some things to consider:

1. I strongly recommend to move tests from #1101 PR from modules meta2.rs, type_names.rs, idl-gen/tests/generator.rs, macros/tests. Passing these tests will fully assure that idl-gen works in accordance to the spec introduce in the mentioned PR
2. Interface ids are already included in the master-idlv2. So checks for repeated definition of the base services done in the macro by comparing string names can be changed to generating const asserts comparing INTERFACE_IDs of base services.
3. idl-gen must not generate the service several times. The check for duplicated interface id can be done in build_program_ast function