Resolve visiblity restrictions imposed by the #[generate_derive(...)] macro.

[rzvxa]

The one thing that could confuse people is visibility. We're used to code generated by #[derive] sitting next to the struct/enum it's derived on, and having access to everything you can "see" from that position. Obviously #[generated_derive] doesn't work like that.

I don't think much we can do about that, but we should document that you have to make structs/enums/fields pub(crate) if you're using #[generated_derive], so people at least understand how to use it.

Or (and very possibly this is a stupid idea), could we make it work like #[derive]? e.g.:

• Generate 1 file of generated code for each source file (not one for each crate).
• Introduce a #[derive_generator] macro.

Then you use #[generated_derive] as follows:

// src/foo.rs
#[derive_generator]
use oxc_allocator::CloneIn;

#[generated_derive(CloneIn)]
struct Foo { // Not pub
    blah: u64 // Not pub
}

#[derive_generator] would expand to:

include!("generated/derive_clonein_foo.rs");

Then the generated code has access to everything in the source file without having to make anything pub (still wouldn't work for a struct which is defined inside a private module {} block, but that's a niche case).

This approach has pluses and minuses... maybe it solves one problem but creates another!

Originally posted by @overlookmotel in oxc-project/oxc#5278 (comment)

[overlookmotel]

@rzvxa Said in oxc-project/oxc#5278 (comment):

What I like about include is the fact that we can have our code outside of the src directory(I'm 90% sure, Haven't tested it), This would allow us to put these stuff in a hidden directory so it isn't accessible from our code base in any other way. If we want to hide away the process then having these files in the generated directory might be more confusing than helpful. It's not like accessing oxc_crate_name/.generated_derives/ is hard.

I actually see it as a downside of using include!() that the code gets hidden away. Yes, that's a closer imitation of #[derive], and originally that's part of what we were trying to do - derive without the compile-time cost of derive macros. But, now that the codegen is working, I actually really like that the generated code is in the crate like any other code, and you can read it - rather than trying to get flaky Rust Analyser to expand a #[derive] for you to see what it's doing.

The only real downside is the visibility thing.

I guess we need to decide: Are we trying to replicate #[derive] as closely as possible (but using different means), or is #[generated_derive] trying to do something different?