-
Notifications
You must be signed in to change notification settings - Fork 14
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
Rewrite most of the crate with updated dependencies #9
Conversation
Some tests sadly still fail due to a bug/missing feature of proc-macro.
It ignores generics of the trait and doesn't generate code for trait items yet.
This is just for testing to see what approach will result in better and shorter code.
There are probably still bugs, but it looks good for now. Additionally, a bunch of documentation was added.
The Fn-type is not really generated yet, but sanity checks are done.
I figured that I changed enough lines, so I might as well add my name :P
Hi @LukasKalbertodt! Thanks so much for taking this on! I'll set some time aside this week to go through it all. I'm really keen to see how it all comes out using the newer APIs, I think |
The feature `proc_macro` was recently stabilized [1]. This has two effects: - The `proc_macro` feature gate is replaced by finer grained feature gates - Using this crate now doesn't need `#![feature(proc_macro)]` but `#![feature(use_extern_macros)]` [1]: rust-lang/rust#52081
@KodrAus I updated the code in response to rust-lang/rust#52081. After this PR is merged, it's time to talk about what nightly features we really want to use. As far as I understand it, the status from the linked PR is what will "land" in Rust 2018. This excludes nice diagnostics (which I use in this PR) and some As I probably already said somewhere, I think it's possible to add a |
@LukasKalbertodt Thanks for your patience on this. I just moved house over the weekend and tried to get to this before then, but missed the boat. This is looking nice and clean! You've done an awesome job. I'm happy to get this merged. As for the |
Awesome, thanks for taking a look and merging!
I think it should be possible to add nightly features on top without restructuring everything, yes. Right now it's mainly So I'll probably make a plan of things I want to do in the next couple of weeks. I'll create issues for everything that is worth discussing (like the two issues I already opened). I hope you don't mind me creating issues and maybe a milestone on your repo? |
Please go right ahead! At this stage I think it's fair to say you've got a much clearer idea of where this crate should go than I do. |
Closes #8
So I'm basically done with rewriting everything. Of course I didn't just rewrite it (just) for fun, but to update
syn
,quote
andproc_macro
. We now use the following versions (the newest as of time of writing):The new implementation can now compile the
compile_test
examples (and more). I guess I reached feature parity. I am not aware that I changed anything about how this crate works. The attribute syntax is the same as before, and I generate the sameimpl
blocks as before (again, as far as I am aware).I think the old and new implementations are somewhat different:
syn
structures to pass information around.syn
data structures and return a token stream.proc_macro::TokenStream
instead of theproc_macro2
version where possible in a useful way.I managed to reduce total line count despite my code having more comments and adding two examples. I guess this is simply due to more ergonomic APIs by
syn
andproc_macro
.As far as I can tell, I improved diagnostics in the new version. Example:
Notes for the Review
I know this is a pretty big PR and reviewing it thoroughly might not be possible, because it would take too long. But I'd appreciate it if you could take a quick look and maybe tell me if anything is still unclear. I can always add more explanations in comments if necessary.
Things I plan on doing after this PR has been merged
(I'd create an issue for each of those points)
cargo test
execute the compile-test and compile-fail testsT
or something simple if it's not taken yet)proc_macro
feature rust-lang/rust#52081). Unfortunately, the API inproc_macro
that allows the nice kind of diagnostics shown above won't be stabilized by that PR and will thus probably remain unstable for a while. We probably should talk about whether we want this to work on stable Rust 2018 or not. Of course, the best solution would be to use awesome diagnostics on nightly and fall back to a less nice solution on stable. But I'm not yet sure how difficult it would be to use such a fallback mechanism.