Compile with stable rust

[fafhrd91]

PyO3 requires following unstable

• const_fn const fn tracking issue (RFC 911) rust-lang/rust#24111
• specialization Tracking issue for specialization (RFC 1210) rust-lang/rust#31844
• use_extern_macros Tracking issue for "macro naming and modularisation" (RFC #1561) rust-lang/rust#35896
• proc_macro (proc_macro_attribute) Tracking issue for "macro naming and modularisation" (RFC #1561) rust-lang/rust#35896
• associated_consts
• Optional, for wrap_function!: concat_idents (Tracking issue for concat_idents rust-lang/rust#29599) Solved with mashup

[tailhook]

Doesn't proc macro work on stable rust? (or just partially) And there is proc-macro2

[messense]

I think currently only proc macro for custom derive works on stable Rust, proc_macro_attribute don't.

[fafhrd91]

proc_macro_attribute is unstable, info is in linked tracking issue.

[tailhook]

Can this trick be used instead of proc_macro_attribute ?

[fafhrd91]

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

[tailhook]

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

I think this is exactly what it does, i.e. given the example:

#[macro_use] extern crate procedural_masquerade;
extern crate proc_macro;

define_proc_macros! {
    #[allow(non_snake_case)]
    pub fn foo_internal__stringify_const(input: &str) -> String {
        format!("const STRINGIFIED: &'static str = {:?};", input)
    }
}

The foo_internal__stringify_const function receives original code and returns generated code. You get a token stream using syn crate as with macros 1.1.

And all this works by wrapping a body of the macro into a type definition to leverage macros 1.1, to get a token stream.

The only difference is that:

#[mod2init]
fn init_function() {
}

Would be written as:

mod2init! {
  fn init_function() {
  }
}

[fafhrd91]

I see. But that would be quite large task, I don’t think I can spend any time on it. Also there is specialization, I am not sure if it possible to avoid it

If you want to work on this task I can give you permission to repo

[fafhrd91]

this features are stable now, const_unsafe_cell_new, const_size_of, const_ptr_null, const_ptr_null_mut

[termoshtt]

Stabilization of TryFrom has been reverted rust-lang/rust#50121

[fafhrd91]

pyo3 does not use TryFrom