Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #49219 - eddyb:proc-macro-decouple, r=alexcrichton
Decouple proc_macro from the rest of the compiler. This PR removes all dependencies of `proc_macro` on compiler crates and allows multiple copies of `proc_macro`, built even by different compilers (but from the same source), to interoperate. Practically, it allows: * running proc macro tests at stage1 (I moved most from `-fulldeps` to the regular suites) * using proc macros in the compiler itself (may require some rustbuild trickery) On the server (i.e. compiler front-end) side: * `server::*` traits are implemented to provide the concrete types and methods * the concrete types are completely separated from the `proc_macro` public API * the only use of the type implementing `Server` is to be passed to `Client::run` On the client (i.e. proc macro) side (potentially using a different `proc_macro` instance!): * `client::Client` wraps around client-side (expansion) function pointers * it encapsulates the `proc_macro` instance used by the client * its `run` method can be called by a server, to execute the client-side function * the client instance is bridged to the provided server, while it runs * ~~currently a thread is spawned, could use process isolation in the future~~ (not the case anymore, see #56058) * proc macro crates get a generated `static` holding a `&[ProcMacro]` * this describes all derives/attr/bang proc macros, replacing the "registrar" function * each variant of `ProcMacro` contains an appropriately typed `Client<fn(...) -> ...>` `proc_macro` public APIs call into the server via an internal "bridge": * only a currently running proc macro `Client` can interact with those APIs * server code might not be able to (if it uses a different `proc_macro` instance) * however, it can always create and `run` its own `Client`, but that may be inefficient * the `bridge` uses serialization, C ABI and integer handles to avoid Rust ABI instability * each invocation of a proc macro results in disjoint integers in its `proc_macro` handles * this prevents using values of those types across invocations (if they even can be kept) r? @alexcrichton cc @jseyfried @nikomatsakis @Zoxc @thepowersgang
- Loading branch information