-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
implement item macros #3086
Comments
What about having different macro defining forms for expression macros and item macros? I don't know that want the behavior to be different based on which delimiter I use. I could also see something like |
It'd be nice if an item macro could expand into multiple (including zero) items. |
In particular, #[auto_serialize] as currently implemented requires |
I agree, expanding to >1 item is probably useful; at the moment you can probably fake it by expanding to a module-full-of-items. |
Two interesting use cases are |
I've been alerted to the fact that X macro-like techniques (see http://stackoverflow.com/questions/264269/what-is-a-good-reference-documenting-patterns-of-use-of-x-macros-in-c-or-possib) may require that we allow macros that can expand either to exprs or to items depending on where they are invoked. This should be possible. I previously didn't think there was any value to it, but I guess I was wrong. |
This is done; open more specific issues if there are bugs. |
Update rustc-ap-* to 272.0.0
Implement SSE3 and SSSE3 intrinsics
Implement SSE3 and SSSE3 intrinsics
Dependency upgrade resulting from `cargo update`.
It's already possible to invoke macros in item position, but
macro_rules
currently only ever produces macros thatmr_expr(...)
. It should be pretty easy to make it produce both kinds of macros. Perhaps(...) => (...)
defines expr macros and(...) => {...}
defines item macros?Ideally, item macros should be able to produce multiple items. This would require changing fold.rs to handle
~[@item]
instead ofoption<@item>
, as it does now. This would require a bit more hacking; perhaps changing the AST to allow sequences of items in more places is an option (it should always be semantically valid, I believe).The text was updated successfully, but these errors were encountered: