Rocket: move compiler plugins to proc macro

[dovahcrow]

Now that proc_macto_attribute has landed, it would be nicer to migrate from old compiler plugin based codegen to the proc_macro.

I'm working on an attempt on my fork using pure proc_macro, syn and quote.

It's just a notice in case of duplicated work from someone else.

[SergioBenitez]

Indeed! Landed in https://github.com/rust-lang/rust/commit/375cbd20cfcc9dbf15682bcfc0081ce5ce95567b, it seems.

While I'm very excited about your eagerness to contribute, I believe it's a bit early to make this transition. The proc_macro feature went through quite a bit of change after landing, and those changes impacted the consumers of libraries using it. I'd rather avoid that kind of impact to Rocket's users. I think we should wait a bit on this.

Nonetheless, I think it's more than prudent to begin _exploring_ migrating Rocket to the new feature. If there are bumps along the way, or things that simply cannot be done with the new API, I'm sure the Rust team would love to be made aware.

[dovahcrow]

After consideration, I decided to make it a separate library that coexists with rocket_codegen.

Benefits are that user can decide which library to use and fallback to the much "stable" rocket_codegen if they seek for no breaking change and since the codegen part is the biggest obstacle of migrating rocket to stable Rust, a proc_macro library after proc_macro_attribute landed in stable rust can drive rocket a big leap toward stable rust.

[SergioBenitez]

Please don't do this. Don't release a library as an alternative to rocket_codegen. This will simply confuse users. rocket_codegen is not static, and neither is rocket. Both are changing often. Features are being added/changed to/in codegen often; any differences between codegen and your library will result in confusion at best and breakage at worst. Further, the interface between core and codegen is not visible to users, and likely will never be, so your library can break without notice, breaking user's applications.

I absolutely encourage you to experiment, and even submit a PR if things come along far enough, but please don't release something that can lead to confusion. There's absolutely no advantage; custom_derive will be around for the foreseeable future, and when proc_macro_attribute matures a bit, Rocket will wholeheartedly migrate to it.

[dovahcrow]

Ah ok, after the library is complete, a PR will be there, no splittism.
On Sun, 29 Jan 2017 at 1:27 PM Sergio Benitez [e-mail]
wrote:

Please don't do this. Don't release a library as an alternative to
rocket_codegen. This will simply confuse users. rocket_codegen is not
static, and neither is rocket. Both are changing often. Features are
being added/changed to/in codegen often; any differences between codegen
and your library will result in confusion at best and breakage at worst.
Further, the interface between core and codegen is not visible to users,
and likely will never be, so your library can break without notice,
breaking user's applications.

I absolutely encourage you to experiment, and even submit a PR if things
come along far enough, but please don't release something that can lead to
confusion. There's absolutely no advantage; custom_derive will be around
for the foreseeable future, and when proc_macro_attribute matures a bit,
Rocket will wholeheartedly migrate to it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/SergioBenitez/Rocket/issues/156#issuecomment-275894953,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA88zohcpOa_216702sAu_m4hz-gycUQks5rXCNNgaJpZM4Lwc9O
.

>

Young Wu
Data Scientist
Data Team, Strikingly
a: 248 Daxue Road, Yangpu District, Shanghai
w: wooya.me e: [email protected]
https://cn.linkedin.com/in/wooya

[dovahcrow]

I've just implement almost all the things including derive, route and error catcher but not route! and errors! macro since the #[proc_macro] has not landed yet. I'll implement the rest as soon as the feature landed.

[SergioBenitez]

Closing this issue for now. We certainly want to move in this direction, but error reporting from proc_macro_attribute is simply not there yet. Additionally, this is part of #19.

[dovahcrow]

Yes, since rocket has detailed error reporting after this issue initiated, I think it is not possible to close this issue in the near future.