-
-
Notifications
You must be signed in to change notification settings - Fork 392
-
-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for #[cfg_attr(cond, generate_derive(x, y, z))]
#5738
Comments
@Boshen marked this as a good first issue since I've almost explained the whole process. Implementing this should allow us to start feature-gating some of our generated derives. All of those feature-gating tasks should also be good first issues since they are in fact trivial compared to this one. Please feel free to remove the good first issue label if you think otherwise Captain. |
Personally I prefer @rzvxa Do you really think parsing the few extra tokens will make a real difference to the Even if it does, we have the beginnings of viable ideas for pre-compiling the macro output in That said, I don't feel super-strongly about this. Happy to go with |
TBH, I didn't time the builds to see how much of an impact it has. However, Since the syn attribute's meta contains the token stream of the arguments we have to parse them explicitly where it didn't before so in theory it does more work. But as always compiler might optimize it down or we don't see the effect because we don't get called too many times(a couple hundred times ain't much). Maybe we should do it with |
@overlookmotel Can you make the call on this one? I'll update the description and title according to your answer. I don't have a strong preference between these two, Treat |
I don't have a hugely strong feeling either. If I had to choose, I'd go for |
cfg_generate_derive
attribute#[cfg_attr(cond, generate_derive(x, y, z))]
We should parse the
cfg_attr
attributes in ouroxc_ast_tools
/oxc_ast_macros
and use them to find conditionalgenerate_derive
usages.This should be implemented in the same way that
generate_derive
works. We need to change thegenerate_derives
field in these 2 types so it'd beVec<(Option</* conditions */ TokenStream>, /* trait name */ String)>
or something similar.oxc/tasks/ast_tools/src/schema/defs.rs
Lines 46 to 87 in 20a7861
After parsing these derives we just have to adjust this part to add the preceding
#[cfg(condition)]
to the output stream of each derive(if there is a condition).oxc/tasks/ast_tools/src/derives/mod.rs
Lines 94 to 102 in 20a7861
With these 2 changes, we should be done with the
oxc_ast_tools
part of it.As for the
oxc_ast_macros
, We want to process them similarly to thegenerate_derive
here:oxc/crates/oxc_ast_macros/src/lib.rs
Lines 71 to 81 in 20a7861
The only difference is that it should output assertions behind a feature flag.
* use
just ast
command to run ast tools on your local environment.The text was updated successfully, but these errors were encountered: