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).