crate-ify and delete unused code from syntax::parse

[Mark-Simulacrum]

This is intended primarily to ensure the compiler catches dead code for us in
more cases.

[rust-highfive]

r? @eddyb

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

[eddyb]

r? @jseyfried @petrochenkov or @pnkfelix

[petrochenkov]

Thanks!
@bors r+

[bors]

📌 Commit 0b4f8e8 has been approved by petrochenkov

[bors]

🔒 Merge conflict

[bors]

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

[Mark-Simulacrum]

@bors r=petrochenkov

[bors]

📌 Commit 60058e5 has been approved by petrochenkov

[bors]

⌛ Testing commit 60058e5 with merge ae0659c...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing ae0659c to master...

[topecongiro]

Is it possible to make some metods public again? I find that the changes introduced in this PR break a few number of tools and libraries that depend on libsyntax.

[Mark-Simulacrum]

Hm, I somewhat expected that tools/libraries like Rocket should mostly be using proc macro's these days, not libsyntax directly. If there's a list of methods/types that need to be made public, I'd be happy to review a PR which makes them pub again.

[tikue]

What about unstable proc macros that relied on these fns?

[Mark-Simulacrum]

I believe the expectation is that even unstable proc macros should be using syn/quote or other libraries for the purpose of parsing Rust code and generating Rust code; they should not be using libsyntax. That is, proc macros shouldn't use #![feature(rustc_private)]. In the specific case of tarpc, it looks like it's using the older plugin registrar functionality, not proc macros -- it should be migrated to proc macros, since those will stabilize far earlier I imagine.

[tikue]

@Mark-Simulacrum Thanks for the quick response. It's been tough to follow the state of proc macros, so I haven't updated things in a while. Last time I tried I ran into cross-crate problems, and the bug I filed, #44817, hasn't been fixed yet. Do you mind giving me a quick pointer to what I should be doing right now?

[Mark-Simulacrum]

I don't believe that there's a way to fix #44817 with proc macros quite yet, and I believe we're unprepared to stabilize anything "hygienic" at this point. For the time being, if you want to fix the issue opened on tarpc I'll approve PRs that re-pub the relevant APIs; long term I imagine there will be a better solution for you. I also haven't looked at how the syntax extensions in tarpc are implemented, it's possible that we already have sufficient functionality for them. If you want, you might be able to get people more familiar with that feature to help on internals or IRC.

[tikue]

@Mark-Simulacrum I tried to get it working with syn but am running into issues. I think the main problem is actually that things like $crate::futures::InfoFuture aren't expanded before being passed to the proc macro, and syn can't parse things like that.

[Mark-Simulacrum]

It's probably best to move this to internals.rust-lang.org, but that feels odd to me. I'd expect syn to be able to parse proc macro input -- including $crate, if that's possible in proc macros.

[tikue]

Ok, so the real problem -- which doesn't seem to have changed since I last tried to move off of plugins -- is that I can't call a proc_macro from inside a macro_rules macro.

error[E0433]: failed to resolve. Did you mean `tarpc::util`?
   --> <_snake_to_camel macros>:2:1
    |
1   |     / ( type $ i : ident = $ t : ty ; ) => {
2   |     | $ crate :: impl_snake_to_camel ! ( type $ i = $ t ; ) ; } ; (
    |     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     | |
    |     | Did you mean `tarpc::util`?

I tried to reexport that proc macro from the tarpc crate root, but doing so doesn't make it visible to the macros declared in tarpc.

If there's no way to do this, then I can't migrate to proc_macro at this time, and would prefer to roll back this PR.