@rzvxa suggested in a Discord conversation that we might want to consider exposing AST codegen as a public crate, so that consumers of Oxc can generate code for acting on AST that's specific to their use case, but would be laborious to write by hand.
My opinion is:
AST codegen is a very powerful tool, and it may well be a good idea to expose it at some point.
We may not want to do that right now. We don't need to expose it, and as it's fairly new, we may have some API changes to make yet.
If/when we do, I think we'd need to break it up into multiple crates/tasks, along these kind of lines:
Task 1 contains:
Code to parse source .rs files and generate the schema (which would include calculating field re-ordering, so offsets in the schema are the final ones).
Public crate contains:
The schema (as generated by Task 1).
Generator types.
Functions to run a generator on the schema and produce the generated output.
Task 2:
Depends on the public crate.
Contains our own collection of generators which we run to generate Visit, CloneIn etc.
I think this is quite a nice separation of concerns, so not such a bad idea. But it would require major refactoring of the codegen (again!), so maybe that's another reason not to do this right now.
Open question: I'm not sure how we'd deal with it if we only do field re-ordering in release mode (due to the Rust Analyser problem). Do we have to generate two schemas for debug mode and release mode?
@rzvxa suggested in a Discord conversation that we might want to consider exposing AST codegen as a public crate, so that consumers of Oxc can generate code for acting on AST that's specific to their use case, but would be laborious to write by hand.
My opinion is:
If/when we do, I think we'd need to break it up into multiple crates/tasks, along these kind of lines:
.rsfiles and generate the schema (which would include calculating field re-ordering, so offsets in the schema are the final ones).I think this is quite a nice separation of concerns, so not such a bad idea. But it would require major refactoring of the codegen (again!), so maybe that's another reason not to do this right now.
Open question: I'm not sure how we'd deal with it if we only do field re-ordering in release mode (due to the Rust Analyser problem). Do we have to generate two schemas for debug mode and release mode?