Skip to content
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

Allow syntax extensions which modify and decorate #33738

Closed

Conversation

dylanmckay
Copy link
Contributor

This adds a new SyntaxExtension type - Renovator.

A renovator is a syntax extension which can modify and decorate the items it is attached to - the union of MultiModifier and MultiDecorator.

This allows things such as syntax extensions which modify existing methods for types, and implement traits all in one.

This shouldn't break any existing code, and it only touches unstable compiler internals.

@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch from afadda2 to 1eab42e Compare May 19, 2016 12:50
@sfackler
Copy link
Member

This has been something I've been meaning to do for a while - I think the whole split into decorators and modifiers was a bad design decision on my part. To that end, I'd like to move towards removing the other variants and making this the only one.

cc @nrc

meta_item: &ast::MetaItem,
item: Annotatable,
push: &mut FnMut(Annotatable))
-> Annotatable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like we can drop the return type and just have implementors push all of the things they're creating/preserving into push?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good idea, I'm adding this in now.

@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch 3 times, most recently from 519c8de to 9251609 Compare May 22, 2016 07:16
@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch 2 times, most recently from 57c0733 to 83a8e22 Compare May 24, 2016 09:55
@bors
Copy link
Contributor

bors commented May 26, 2016

☔ The latest upstream changes (presumably #33766) made this pull request unmergeable. Please resolve the merge conflicts.

@sfackler
Copy link
Member

Looks like travis is failing and it needs a rebase. Looks good to me otherwise though.

r? @nrc

@rust-highfive rust-highfive assigned nrc and unassigned sfackler May 26, 2016
@nrc
Copy link
Member

nrc commented May 27, 2016

cc @cswords
Looks fine to me too. Note that we are looking at revamping syntax extensions completely over the next few months, so this is all likely to disappear. However, it's probably worth landing this since new syntax extensions will be closer to these Renovators than to the existing flavours.

@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch 2 times, most recently from a64bb3a to d0c8eba Compare May 27, 2016 09:31
@dylanmckay
Copy link
Contributor Author

dylanmckay commented May 27, 2016

Travis seems to be having unrelated issues. apt-get update is failing.

@bors
Copy link
Contributor

bors commented May 28, 2016

☔ The latest upstream changes (presumably #33706) made this pull request unmergeable. Please resolve the merge conflicts.

@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch from d0c8eba to 14a8f0a Compare May 28, 2016 05:17
@dylanmckay
Copy link
Contributor Author

Am working on fixing this up.

@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch 7 times, most recently from b7a0f2c to 58d1ae6 Compare June 5, 2016 06:08
@dylanmckay
Copy link
Contributor Author

@nrc: Have rewritten the PR so that renovators must push all items which they want to preserve.

This is ready for review.

@nrc
Copy link
Member

nrc commented Jun 7, 2016

Why must users push the items themselves? That seems a bit counter-intuitive. At the least it needs to be documented somewhere.

Given that the renovator behaviour is a strict super-set of decorator and modifier, it would be cool to see their code refactored to just use the renovator code. Would that be possible?

@dylanmckay
Copy link
Contributor Author

Why must users push the items themselves?

@nrc: @sfackler suggested this behaviour in this comment. I agree with it, and it gives the most flexibility to extensions.

Happy to document it more.

Given that the renovator behaviour is a strict super-set of decorator and modifier, it would be cool to see their code refactored to just use the renovator code. Would that be possible?

It's tricky to merge the three, as there is special handling for the new things that modifiers create. I can merge the Decorator and Renovator expansion code however.

This adds a new SyntaxExtension type - Renovator.

A renovator is a syntax extension which can modify *and* decorate the
items it is attached to - the union of `MultiModifier` and
`MultiDecorator`.

This allows things such as syntax extensions which modify existing
methods for types, and implement traits all in one.
@dylanmckay dylanmckay force-pushed the more-flexible-syntax-extensions branch from 58d1ae6 to dbd5017 Compare June 8, 2016 09:40
@bors
Copy link
Contributor

bors commented Jun 8, 2016

☔ The latest upstream changes (presumably #34010) made this pull request unmergeable. Please resolve the merge conflicts.

@nrc
Copy link
Member

nrc commented Jun 8, 2016

@nrc: @sfackler suggested this behaviour in this comment. I agree with it, and it gives the most flexibility to extensions.

Happy to document it more.

Ok, that sounds good, more docs would be good though.

It's tricky to merge the three, as there is special handling for the new things that modifiers create. I can merge the Decorator and Renovator expansion code however.

What about the new things renovators create? Is this not the same handling?

@dylanmckay
Copy link
Contributor Author

What about the new things renovators create? Is this not the same handling?

Modifiers have this special handling expand all the new stuff from the modifier. Decorators and renovators don't need it.

@nrc
Copy link
Member

nrc commented Jun 10, 2016

Why don't renovators need it, I'd have thought a renovator which doesn't create new items should behave exactly like a modifier?

@dylanmckay
Copy link
Contributor Author

No idea, it's just what the current code does.

On Sat, Jun 11, 2016 at 2:51 AM, Nick Cameron [email protected]
wrote:

Why don't renovators need it, I'd have thought a renovator which doesn't
create new items should behave exactly like a modifier?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#33738 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AHXUrzYwCxP4zuHAVRaL3QwtKavuNMQxks5qKXoMgaJpZM4IiK3Y
.

@nrc
Copy link
Member

nrc commented Jun 23, 2016

This PR is superseded by #34253 which achieves a similar goal without adding a new class of macro. Sorry this PR didn't get to land and thanks for submitting it.

@nrc nrc closed this Jun 23, 2016
@dylanmckay dylanmckay deleted the more-flexible-syntax-extensions branch February 4, 2017 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants