Tweak ItemDecorator API #12234
Merged
Tweak ItemDecorator API #12234
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -233,12 +233,13 @@ pub fn expand_mod_items(module_: &ast::Mod, fld: &mut MacroExpander) -> ast::Mod | |||
| span: None | |||
| } | |||
| }); | |||
| let r = dec_fn(fld.cx, attr.span, attr.node.value, items); | |||
| items.push_all(dec_fn(fld.cx, attr.span, attr.node.value, *item)); | |||
There was a problem hiding this comment.
I wonder if this would be noticeably more efficient as
dec_fn(fld.cx, attr.span, attr.node.value, *item, |new| items.push(new))after modifying ItemDecorator to take a pusher: |@Item| as the last argument.
There was a problem hiding this comment.
Not sure. I think that this PR keeps roughly the same allocation patterns as before.
There was a problem hiding this comment.
Doesn't mean we have to repeat them :)
|
@huonw updated |
|
r=me if you update the commit message & pr description to match the fact it's passing in a callback, not returning the vector. |
The old method of building up a list of items and threading it through all of the decorators was unwieldy and not really scalable as non-deriving ItemDecorators become possible. The API is now that the decorator gets an immutable reference to the item it's attached to, and a callback that it can pass new items to. If we want to add syntax extensions that can modify the item they're attached to, we can add that later, but I think it'll have to be separate from ItemDecorator to avoid strange ordering issues.
bors
added a commit
that referenced
this pull request
Feb 14, 2014
The old method of building up a list of items and threading it through all of the decorators was unwieldy and not really scalable as non-deriving ItemDecorators become possible. The API is now that the decorator gets an immutable reference to the item it's attached to, and a callback that it can pass new items to. If we want to add syntax extensions that can modify the item they're attached to, we can add that later, but I think it'll have to be separate from ItemDecorator to avoid strange ordering issues. @huonw
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
@huonw