-
Notifications
You must be signed in to change notification settings - Fork 13.4k
implement item macros #3086
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: