-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add an ItemModifier syntax extension type #12617
Conversation
@@ -37,6 +37,9 @@ pub struct MacroDef { | |||
pub type ItemDecorator = | |||
fn(&mut ExtCtxt, Span, @ast::MetaItem, @ast::Item, |@ast::Item|); | |||
|
|||
pub type ItemModifier = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you're adding a new type, could you add docs for it now?
What is the background for why we are doing this? |
There's an issue that I can't find right now to add an attribute to automatically insert extern function prefixes like this: #[prefix("foobar_")]
extern {
fn func_1();
fn func_2();
}
// expands to...
extern {
fn foobar_func_1();
fn foobar_func_2();
} @kballard and I were talking at the last meetup about another use case he had for wrapping functions in some bookkeeping code necessary for safety when interacting with LUA. I think the idea is something like this: #[lua_safety]
fn foo() {
//...
}
// expands to...
fn foo() {
fn inner_foo() {
//...
}
// LUA setup
inner_foo();
// LUA cleanup
} He would know more details though. |
Yeah, I was talking with @sfackler about this at the meetup. Right now I have a I also thought that this ability would allow |
Actually, given my musings about |
I'd hesitate to return a |
Returning an item with an ItemDecorator attached didn't occur to me. Possibly a bit confusing though. As for returning none, if my ItemModifier determines it doesn't want any item, returning something with #[cfg(blah)] is downright odd. |
ping @sfackler, with @huonw's comment addressed, I think this may be mergeable. The API of libsyntax will likely be @brson, are you ok with merging under that logic? |
Yes. +1
|
Sounds good. I'll update it tomorrow night. |
Updated |
Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item. cc @huonw
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local Fixes rust-lang#12616 `Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local Fixes rust-lang#12616 `Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
The job Click to see the possible cause of the failure (guessed by this bot)
|
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local Fixes rust-lang#12616 `Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
Where ItemDecorator creates new items given a single item, ItemModifier
alters the tagged item in place. The expansion rules for this are a bit
weird, but I think are the most reasonable option available.
When an item is expanded, all ItemModifier attributes are stripped from
it and the item is folded through all ItemModifiers. At that point, the
process repeats until there are no ItemModifiers in the new item.
cc @huonw