[Feat]: Automated IDL generation is missing

[Brymes]

Comparison of IDL Implementation Approaches in Steel

Approach	Pros	Cons	Notes
Convert account! and other macros to a Proc Macro (and re-export)	- Zero changes to user code if re-exported - Can capture struct metadata directly at macro expansion - Can emit perfect IDL coverage - Fun to build	- More complex to implement - Afraid I may break the codebase as Steel doesn’t contain any tests	Recommended if Steel can change internally; matches what Anchor does. Users write code as before.
macro_rules! + Source Code Scanner/Codegen Tool	- Zero changes to user code - Tooling runs outside build process (CLI)	- May miss edge cases if user doesn’t follow conventions - Extra moving part (external CLI tool) - Less precise - Less fun to build	- Useful as a fallback if macro conversion is impossible; similar to what some frameworks do.
Standalone Derive Macro + Registry	- Users just add a derive (e.g., #[derive(IdlAccount)]) to their structs - Accurate IDL collection - Registry-based approach (like schemas)	- Less fun to build - Requires a small change to each struct definition - More boilerplate for users	Cleaner than source scanning, but not “zero change”;
Shank Macro	- Easiest approach - Handles complex type mappings with #[idl_type] - Supports custom field/documentation attributes - IDL extraction via mature CLI - Community support	- More Boilerplate on user code using Shank macros (#[derive(ShankAccount)], etc.) - It’s An EXTERNAL DEPENDENCY - Less fun to build

Details

1. Proc Macro Conversion (Best)

• Refactor account! to a function-like proc macro, move it to steel-syn.
• Use syn to parse struct and enum.
• Register metadata for IDL at macro expansion.
• Re-export from steel so users don’t change import paths.
• IDL is emitted by a build script, e.g. build.rs.

User code stays exactly the same:

account!(MyAccount, Counter);

2. Source Code Scanner/Codegen

• CLI tool parses Rust files for account! usages and struct definitions.
• Completely external; no changes to macros or codebase.
• Easiest to integrate, but lowest precision.
• Builds IDL by walking the source tree.
• No changes to user code, but requires developers to run a CLI step.

3. Derive Macro + Registry

• Users add #[derive(IdlAccount)] to their account structures.
• Each invocation registers type info for IDL.
• Requires the user to touch every struct (minor boilerplate).

4.Shank Macro

• Users add Shank macros (#[derive(ShankAccount)] e.t.c) to their structs.
• Each invocation registers type info for IDL.
• External Dependency but proven to work
• Developed by MetaPlex