Miri fails in many ways on `awint`

[AaronKutch]

Previously, my awint repo was unified under two crates in a workspace, but when I split them up Miri started failing in many ways. Here are all the ways I know (note: run cargo clean before each case):

• cargo miri test (note: disable awint/tests/fuzz_all.rs or else the tests may take a long time) results in "found possibly newer version of crate core" error.
• cargo test && cargo miri test results in Miri trying to interpret an exe file as JSON
• cargo miri test && cargo test results in a bizarre error where it says it could not execute a process and gives no reason

[RalfJung]

Did you try a new clean checkout? When switching between workspace and non-workspace, I am not sure if cargo clean really cleans everything.

The last two are kind of expected; mixing Miri and non-Miri builds sometimes leads to strange issues. Cc #1311

[AaronKutch]

I made sure to clean all target folders. When I run cargo miri test in the crate root or in awint_macros it will produce

error[E0460]: found possibly newer version of crate `core` which `awint_ext` depends on
  --> /home/aaron/awint/awint_macros/src/lib.rs:48:5
   |
48 | use awint_ext::ExtAwi;
   |     ^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `core`: /home/aaron/.cache/miri/HOST/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-a9d323fd54706b19.rmeta
           crate `awint_ext`: /home/aaron/awint/target/debug/deps/libawint_ext-1c5395bbb4013659.rmeta

@AaronKutch Did that happen during doctest?

[AaronKutch]

It happens during Doc-tests. You can clone my repo and try with the nightly compiler.

It happens because Miri sysroot is passed to rustdoc for a procedural macro crate, which should always use the "normal" sysroot. But just fixing the sysroot doesn't work -- doctests of procedural macro crates are always built and run for the host, all --extern crates are host crates.

[RalfJung]

I recall we had trouble with proc macro tests before... that was proc macro unit tests I assume? Can we do the same with proc macro doctests?