how to create an ident from a string

[softprops]

I'm in the process of a crate from 0.11 => 0.15.22 ( the latest as of today ) and am trying to figure out what the equivalent of 0.11's From impl for strs is in the latest release. Ident::from(format!("{}Key", name)) . There is a new method but requires proc_macro2 for Span::call_site() however this Span comes from the proc_macro2 crate which I haven't needed to depend on yet. I see that the rust proper proc_macro crate has a stable version of that here

Is there a way to construct an Ident in the latest syn without pulling in the proc_macro2 crate?

[hcpl]

syn depends on proc-macro2 already, so depending on it yourself shouldn't add a new entry to the dependency set of your crate.

[softprops]

👍

[softprops]

closing because I fold. I couldn't find a Span re-import in syn so I had to add a new declared dependencies on proc_macro2 in my Cargo.toml file. I'm wondering if this dependency is actually still useful for this particular use case, especially because Span::call_site in the proc macro is stable.

[hcpl]

One of the main reasons proc-macro2 exists is to support current proc-macro API on all stable Rust versions back to 1.15. I think this particular design restriction is motivated a lot by serde_derive which promised to work on Rust >=1.15 since its 1.0.0 release and today is still 1.0.* which disallows breaking changes.

[dtolnay]

The 1.15 compatibility is a side benefit. The main reason is that none of the data structures from extern crate proc_macro can be used outside of the context of a procedural macro. If Syn were implemented against proc_macro types, that would make it unusable in a build.rs or main.rs. By using proc-macro2 we support those use cases in addition to the procedural macro use case.

I would like to see even more code move to proc-macro2 by having the compiler accept proc-macro2 types in the signature of #[proc_macro_derive] functions. That way nothing would depend on extern crate proc_macro except for within the implementation of proc-macro2.

[hcpl]

The main reason is that none of the data structures from extern crate proc_macro can be used outside of the context of a procedural macro. If Syn were implemented against proc_macro types, that would make it unusable in a build.rs or main.rs.

Yeah, I forgot that I used syn in a build.rs once which was possible thanks to proc-macro2.

I would like to see even more code move to proc-macro2 by having the compiler accept proc-macro2 types in the signature of #[proc_macro_derive] functions. That way nothing would depend on extern crate proc_macro except for within the implementation of proc-macro2.

With rust-lang/rust#49219 using proc_macro in non procedural macro contexts should be possible on latest beta and nightly. Does that mean proc-macro2 now only has a "Rust 1.15 compatibility layer" use-case for Rust >=1.32?

[dtolnay]

@hcpl rust-lang/rust#49219 is not related to this. It does not make proc_macro usable outside of a procedural macro. It is still the case that proc-macro2 is required if I want to support build.rs and main.rs use cases. Try running:

extern crate proc_macro;
use proc_macro::{Ident, Span};

fn main() {
    println!("{}", Ident::new("i", Span::call_site()));
}

[hcpl]

Huh, I didn't follow the thread and assumed that decoupling proc_macro implies refactoring the internals to be like proc-macro2 and the ability to upload proc_macro to crates.io, but IIUC that PR was just about internal modularization to not use dynamic linking. My bad.