diff options
| author | bors <bors@rust-lang.org> | 2018-11-30 06:44:14 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2018-11-30 06:44:14 +0000 |
| commit | d48ab693d1ce99f30c0cf9abdf45c209824fe825 (patch) | |
| tree | 83dfb826fd7ff387e79c3e4c4c7ddd7d5317eba6 /src/libstd/net/tcp.rs | |
| parent | 3e90a12a8a95933604a8b609197fce61bb24a38c (diff) | |
| parent | 3a04d448f935dcd8ed0e5ff98e776431196a4ece (diff) | |
| download | rust-d48ab693d1ce99f30c0cf9abdf45c209824fe825.tar.gz rust-d48ab693d1ce99f30c0cf9abdf45c209824fe825.zip | |
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
Diffstat (limited to 'src/libstd/net/tcp.rs')
0 files changed, 0 insertions, 0 deletions
