Open overlookmotel opened 2 months ago
This one is fairly complex. Give me some time to digest the ideas. But I'm kind of on board with the "include" already; Just need some time to process it and come back with comments.
I'm mostly worried about the manual import of these files. We should make them internal and unexposable to the users somehow. Maybe we can have them outside of the src directory so nobody can use them as valid Rust modules. But having source files outside of src makes me worried about crate and how the publish works.
@rzvxa and I have been discussing various ways to make macros cheaper on compile time, for example the
#[ast]
macro.I had another idea in this vein. How about this:
#[ast]
,ast_tools
would output a separate file.oxc_ast/src/ast/js.rs
, then the codegen would write tooxc_ast/.macro_expansions/src/ast/js.rs/<line number>.rs
.#[ast]
macro does now).#[ast]
macro would expand to:Example
Original type def:
ast_tools
writes to file:#[ast]
macro's implementation is very simple indeed:Spans
I've not tested this out, so I don't know for sure it'll work. In particular, I wonder if spans/hygiene will get mashed up so Rust Analyser may lose "jump to definition" etc.
Maybe we can work around that by outputting a
macro_rules!
macro. e.g.ast_tools
writes this to the file:Then
#[ast]
macro would output a token stream:That's a bit more involved, but still can be done just by concatenating
TokenStream
s, which is much cheaper thansyn
.Actually I'm not sure how to get proc macro to output
macro_123!
, as the proc macro doesn't know the line number. Maybe proc macro has to hash the input stream and use that as the UID instead of line number. Hashing withFxHash
is fairly cheap.Or maybe it searches through the input
TokenStream
for the tokenstruct
orenum
, and then the UID is the token that follows (which will be the type name).What do you think, @rzvxa?