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
If the Rust LLVM fork is used, enable the -mergefunc-use-aliases
flag, which will create aliases for merged functions, rather than
inserting a call from one to the other.
A number of codegen tests needed to be adjusted, because functions
that previously fell below the thunk limit are now being merged.
Merging is prevented either using -C no-prepopulate-passes, or by
making the functions non-identical.
I expect that this is going to break something, somewhere, because
it isn't able to deal with aliases properly, but we won't find out
until we try :)
This fixes#52651.
I noticed on a [recent build][1] that the linkchecker stage of CI took a
whopping 15 minutes of CI time for something that should be near
instantaneous. Some local profiling showed some very hot functions and
clones which were pretty easy to remove, and now instead of running in
minutes locally it runs in seconds.
[1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve#54981.
libcore: Add VaList and variadic arg handling intrinsics
## Summary
- Add intrinsics for `va_start`, `va_end`, `va_copy`, and `va_arg`.
- Add `core::va_list::VaList` to `libcore`.
Part 1 of (at least) 3 for #44930
Comments and critiques are very much welcomed 😄
