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

1 files changed, 48 insertions, 0 deletions

diff --git a/src/test/ui/proc-macro/macro-namespace-reserved.rs b/src/test/ui/proc-macro/macro-namespace-reserved.rs
new file mode 100644
index 00000000000..b0a3dbf0c1f
--- /dev/null
+++ b/src/test/ui/proc-macro/macro-namespace-reserved.rs
@@ -0,0 +1,48 @@
+// Copyright 2018 The Rust Project Developers. See the COPYRIGHT
+// file at the top-level directory of this distribution and at
+// http://rust-lang.org/COPYRIGHT.
+//
+// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
+// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
+// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
+// option. This file may not be copied, modified, or distributed
+// except according to those terms.
+
+// force-host
+// no-prefer-dynamic
+
+#![feature(decl_macro)]
+#![crate_type = "proc-macro"]
+
+extern crate proc_macro;
+use proc_macro::*;
+
+#[proc_macro]
+pub fn my_macro(input: TokenStream) -> TokenStream {
+    input
+}
+
+#[proc_macro_attribute]
+pub fn my_macro_attr(input: TokenStream, _: TokenStream) -> TokenStream {
+    input
+}
+
+#[proc_macro_derive(MyTrait)]
+pub fn my_macro_derive(input: TokenStream) -> TokenStream {
+    input
+}
+
+macro my_macro() {} //~ ERROR the name `my_macro` is defined multiple times
+macro my_macro_attr() {} //~ ERROR the name `my_macro_attr` is defined multiple times
+macro MyTrait() {} //~ ERROR the name `MyTrait` is defined multiple times
+
+#[proc_macro_derive(SameName)]
+pub fn foo(input: TokenStream) -> TokenStream {
+    input
+}
+
+#[proc_macro]
+pub fn SameName(input: TokenStream) -> TokenStream {
+//~^ ERROR the name `SameName` is defined multiple times
+    input
+}