Run proc macro invocations in separate threads.

[eddyb]

#49219 introduces proc_macro::bridge::server::{ExecutionStrategy,SameThread,CrossThread}.
SameThread had to be used because CrossThread was a significant performance regression.

Ideally, we'd use CrossThread, which spawns a thread for each invocation, to prevent (and discourage) proc macros from using TLS for state between invocations.

But we'd have to figure out how to make it not regress performance too much, if at all possible.
(it could be the use of channels, which are overkill since they never have more than one value)

cc @dtolnay @alexcrichton @petrochenkov

---

(TODO: update with regressions, if any, after the cross-thread crater run finishes on #49219)

[Mark-Simulacrum]

proc macros from using TLS for state between invocations

As a preliminary "fix" we could probably prohibit thread_local generation within proc-macro crates?

---

I'm also not quite sure what the reasoning behind this being undesirable is, and I think it would be good to include that in this issue so that the cost/benefit could be better analyzed.

[eddyb]

@Mark-Simulacrum Proc macros shouldn't have state between invocations, as we don't want to guarantee any particular execution order, and also incremental macro expansion wouldn't want to always re-run all the invocations.

If necessary, we can make the incremental expansion integration opt-in, but I hope we don't have to (as most proc macros, especially derives, are stateless).

[Mark-Simulacrum]

Okay -- so mostly essentially non-technical reasons? That's what I expected.

I think the main reason why I feel like thread isolation is not super helpful is that it seems like then people will just move to static + Mutex or something along those lines (i.e., not actually solving the problem, just moving it and introducing potential deadlocks...).

[Centril]

@Mark-Simulacrum I think we need to be more clear about not guaranteeing execution order in documentation and such; is this even documented anywhere right now?

[eddyb]

@Mark-Simulacrum One thing I forgot to mention is that the proc_macro API types cannot be sent between threads, so you're stuck to using TLS if you want to keep any of them.

But with #49219, methods will panic (including drop from e.g. dropping the TLS slot!) when called from a different expansion (or from outside an expansion) than the one an object was created in.

[jaynagpaul]

Is there any possible workaround for maintaining state between proc macros invocations? If not are there plans for a solution?

[Mark-Simulacrum]

What is the use case for that?

[jaynagpaul]

@Mark-Simulacrum A mini web framework, looked at a couple of solutions, the two I've found so far is generating functions which is used by rocket and reset-router. Currently sparkles is using thread local state and it is what I was leaning towards before finding this issue. It has the added benefit of avoiding reset-router + rocket's namespacing problem

[eddyb]

Is what you want to do possible if we randomized the order we expand things in? If not, you shouldn't do it.

OTOH, there may be something you could do by having a proc macro attribute on a module or entire crate (I don't think we currently support it, but it would allow more interesting transformations).

[ishitatsuyuki]

Regarding the performance issues, could pipelining be a potential approach? I'm not sure how complex would it be to implement, but as proc macros are mainly dealing transformations, not the value of Span itself, pipelining definitely can reduce RPC overhead here.

[oli-obk]

@ishitatsuyuki I don't know what pipelining is. Can you explain your idea in more detail and/or give an example what would be different?

[ishitatsuyuki]

@oli-obk The idea is that the client turns what would be a RPC (IPC/FFI, whatever) call into an embedded object in the final result instead. What I'm referring to by "pipelining" is this:

In detail, I would be using Span transformation as an example.

The client side Span handle would be like:

pub struct SpanHandle {
    Id(usize),
    CallSite,
    Parent(Box<SpanHandle>),
    // ... other values returned by functions
}

Functions on Span (client-side) would return results without contacting the server-side, and these results are serialized into the final TokenStream, sent to the server, and then finally the functions will actually execute.

[eddyb]

Ah so this is a symbolic execution scheme for RPC calls, building a tree/DAG of operations that is only evaluated when absolutely necessary. I think with an arena for allocation this could be pretty efficient.

Also, you can use integer IDs by pushing these to a buffer.

cc @nikomatsakis Neat trick!
@alexcrichton @dtolnay How would you feel about something like this? I don't have the time right now to prototype it but it sounds fun and potentially useful.

(I just realized it would make hashing and equality checks more expensive for Ident and Span since it couldn't use the integer ID without checking it's not an unevaluated request)

[nagisa]

A technical reason could be to better report (and isolate) misbehaving proc-macros.

[programmerjake]

Would this open a path for running proc-macros as separate processes communicating with rustc over a pipe or unix-socket-like thing? That would be handy for being able to run statically linked versions of rustc on platforms without a dynamic linker. I'd imagine each proc-macro process should be able to handle multiple macro expansions without having to terminate and respawn for each one.

[shepmaster]

Adding a reproducible failure case after finding the same problem as #86556:

use serde::Deserialize;
use serde_json; 

struct Coord(f64, f64);

impl<'de> Deserialize<'de> for Coord {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: serde::de::Deserializer<'de>,
    {
        #[derive(Deserialize)]
        struct Inner {
            x: f64,
            y: f64,
        }
        
        let Inner { x, y } = Inner::deserialize(deserializer)?;
        Ok(Coord(x, y))
    }
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let db_content = r#"[{"x":1.0,"y":1.0},{"x":2.0,"y":17.0}]"#;
    let _: Vec<(f64, f64)> = serde_json::from_str(db_content)?;
    Ok(())
}

[dependencies]
serde = { version = "=1.0.126", features = ["derive"] }
serde_json = "=1.0.64"

Moving the Inner struct out of the impl Deserialize avoids the stack overflow.

[d-sauter]

Not sure if this is the exact goal of this thread, but I have a usecase where I have a derive macro used on structs to implement some trait. I would like an enum containing every struct that derived this type. For example

If i had

#[derive(SomeTrait)]
struct A {}

#[derive(SomeTrait)]
struct B {}

I would like to generate:

enum SomeEnum {
    A,
    B,
}