This commit goes through all proc-macros we have in this repository and
ensures that they're all flagged with `test = false` and `doctest =
false`. This comes about as I was curious why CI time was 40m which felt
a little long and upon inspection the cross-compiled builders were
taking upwards of 30 minutes just to build everything (not including
running tests) where the non-cross-compiled builders took only about
10-15 minutes to build everything.
Further investigation into this discrepancy showed that a lot of crates
are being double-compiled in a cross-compiled situation. This is
expected at a base level and something Cargo transparently handles, for
example if a build script and the final binary need the same dependency
then it's gotta get compiled twice. What was odd is that large portions
of the Wasmtime crate graph were being compiled more than they should
be.
I tracked this down to some `dev-dependencies` for procedural macros
pointing at wasmtime crates. This makes sense for the `tests/*.rs`-style
tests which are always compiled for the target, but tests for the
proc-macro itself would be compiled for the host. By disabling tests and
doctests for the proc macro itself this removes the need for the
host-compiled version of these dependencies.
Overall this reduces a full compile of all tests from ~840 units of work
to 700 units of work according to Cargo. The set of extra crates
compiled in a cross-compiled workflow is not much smaller than in a
non-cross-compiled workflow and they all generally "make sense" as core
shared dependencies which are rooted in both Wasmtime and some
proc-macro's dependency tree, for example.
This crate exists to solve a very peculiar problem for the
wasi-preview1-component-adapter: we want to use string literals in our
source code, but the resulting binary (when compiled for
wasm32-unknown-unknown) cannot contain any data sections.
The answer that @sunfishcode discovered is that these string literals, if
represented as an array of u8 literals, these will somehow not end up in the
data section, at least when compiled with opt-level='s' on today's rustc
(1.69.0). So, this crate exists to transform these literals using a proc
macro.
It is very possible this cheat code will abruptly stop working in some future
compiler, but we'll cross that bridge when we get to it.
Alex Crichton
d308dbdcda