DOCS_RS=1 cargo build fails, even with a patch to proc-macro2

[wtdcode]

DOCS_RS=1 cargo build fails with (note a cargo clean is crucial to reproduce):

error[E0277]: the trait bound `proc_macro2::Span: From<proc_macro::Span>` is not satisfied
   --> /home/mio/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/proc-macro-error2-2.0.1/src/lib.rs:554:32
    |
554 |                 first: (*self).into(),
    |                                ^^^^ the trait `From<proc_macro::Span>` is not implemented for `proc_macro2::Span`
    |
    = note: required for `proc_macro::Span` to implement `Into<proc_macro2::Span>`

error[E0277]: the trait bound `proc_macro2::Span: From<proc_macro::Span>` is not satisfied
   --> /home/mio/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/proc-macro-error2-2.0.1/src/lib.rs:555:31
    |
555 |                 last: (*self).into(),
    |                               ^^^^ the trait `From<proc_macro::Span>` is not implemented for `proc_macro2::Span`
    |
    = note: required for `proc_macro::Span` to implement `Into<proc_macro2::Span>`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `proc-macro-error2` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

I have a PR to fix proc-macro-error2: dtolnay/proc-macro2#501 but even with that, dynasm gives new errors. To reproduce, add these lines to Cargo.toml:

[patch.crates-io]
# Track issue: https://github.com/dtolnay/proc-macro2/pull/501
proc-macro2 = { git = "https://github.com/wtdcode/proc-macro2", branch = "impl-proc-macro-span" }

This passes DOCS_RS=1 cargo build but unfortunately any users (including us, LibAFL) using dynasmrt::dynasm! will still gets an error. This looks a fault in dynasm crate and thus I reported it here.

To reproduce, build a simple test DOCS_RS=1 cargo build --test aarch64_immediate_checking would reproduce. Note cargo clean is still necessary to reproduce this.

... (removed many duplicate errors)
error[E0425]: cannot find value `ops` in this scope
    --> testing/tests/aarch64_immediate_checking.rs:10:9
     |
10   | /         dynasmrt::dynasm!($ops
11   | |             ; .arch aarch64
12   | |             $($t)*
13   | |         )
     | |_________^ not found in this scope
...
1036 | /     dynasm!(ops
1037 | |         ; fmov v1.d2, hide(0.0)
1038 | |     );
     | |_____- in this macro invocation
     |
     = note: this error originates in the macro `dynasmrt::dynasm` which comes from the expansion of the macro `dynasm` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0425`.
error: could not compile `testing` (test "aarch64_immediate_checking") due to 85 previous errors

Related issue: GnomedDev/proc-macro-error-2#12

[wtdcode]

Addon: can only reproduce on stable toolchain.

[CensoredUsername]

I seem to be unable to reproduce this, what rustc/cargo versions are you on?

[wtdcode]

I seem to be unable to reproduce this, what rustc/cargo versions are you on?

We are on cargo 1.87.0 (99624be96 2025-05-06)

[CensoredUsername]

Ah I figured out how to reproduce it.

If you build it normally first, and then build it with DOCS_RS=1 it passes, I had to fully clean artifacts inbetween. That is very odd.

[wtdcode]

That's why I emphasized note a cargo clean is crucial to reproduce

[CensoredUsername]

I completely managed to read over that, oops.

[CensoredUsername]

Expanding the macro actually works fine with DOCS_RS=1, so it seems like some kind of hygiene issue is at fault here that for some reason only happens when DOCS_RS=1 is set, unless an unstable compiler is used. Annoyingly, even just trying to backtrace the macro on a stable compiler using RUSTC_BOOTSTRAP=1 to cheat into being able to use -Zmacro-backtrace seems to work just fine (after a few more patches to proc-macro2).

I'm trying to trace the cause. It seems to start at https://github.com/dtolnay/proc-macro2/blob/master/build.rs#L32 , where DOCS_RS being set causes different configuration variables to be set in proc_macro2. One of those configuration variables probably breaks things.

To be specific, DOCS_RS=1 causes both the cfgs procmacro2_semver_exempt, and super_unstable to be activated for proc_macro2. According to the code in built.rs:

    if semver_exempt && proc_macro_span {
        // Implement the semver exempt API in terms of the nightly-only
        // proc_macro API.
        println!("cargo:rustc-cfg=super_unstable");
    }

Indicating that it now might use unstable, nightly-only APIs for proc-macro processing. Doing this on a stable compiler probably has some issues, which you are probably encountering.

Based on this, I don't think this is a dynasm-rs issue. Setting the DOCS_RS=1 flag for proc_macro2 seems to enable some options that should really not be enabled when being used in proc macros on a stable compiler.

Although I am not quite sure where this is actually causing the breakage. I couldn't immediately find out where these flags being set would change the behaviour of the proc_macro2 crate as I shouldn't be using any semver exempt APIs.

[wtdcode]

This corresponds to my investigation here: GnomedDev/proc-macro-error-2#12 (comment)

I'm also not sure the root cause and dtolnay seems ignored my PR and related issues, unfortunately.

Is it possible to skip related macros in dynasm-rs side, like by gating it by some features only enabled during DOCS_RS=1?

[CensoredUsername]

The thing that is breaking is the hygiene of the initial argument to the dynasm! macro, which is kind of the point of the entire crate. I could disable its contents when it is called with DOCS_RS=1, but then the entire test suite would be nop'd.

I suppose we could just not build the testing crate when DOCS_RS=1? It shouldn't need to be documented anyway.

[wtdcode]

That is enough for dynasm-rs but not for the crates which depends on it. The culprit is dynasm! macro breaking. Maybe just a dumb implementation for dynasm! macro when DOCS_RS=1?

…

________________________________ From: CensoredUsername ***@***.***> Sent: Thursday, May 22, 2025 12:47:57 AM To: CensoredUsername/dynasm-rs ***@***.***> Cc: lazymio ***@***.***>; Author ***@***.***> Subject: Re: [CensoredUsername/dynasm-rs] `DOCS_RS=1 cargo build` fails, even with a patch to `proc-macro2` (Issue #114) [https://avatars.githubusercontent.com/u/3411575?s=20&v=4]CensoredUsername left a comment (CensoredUsername/dynasm-rs#114)<#114 (comment)> The thing that is breaking is the hygiene of the initial argument to the dynasm! macro, which is kind of the point of the entire crate. I could disable its contents when it is called with DOCS_RS=1, but then the entire test suite would be nop'd. I suppose we could just not build the testing crate when DOCS_RS=1? It shouldn't need to be documented anyway. — Reply to this email directly, view it on GitHub<#114 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULOZWF7DTDQA5E2LMZF327SU33AVCNFSM6AAAAAB5LVNABOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJYGYYDQNZUGI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[CensoredUsername]

I'm unsure of this, it'd be nicer if the actual issue could be resolved instead of adding hacks around more hacks. proc_macro2 behaving differently on a DOCS_RS=1 build is a pretty significant issue to begin with.