Windows: failed when running cargo-doc; no such subcommand: +nightly

[Bromeon]

Steps to reproduce the bug with the above code

On Windows 10:

git clone https://github.com/Bromeon/js-sandbox.git
cd js-sandbox
cargo semver-checks check-release -p js-sandbox

Actual Behaviour

cargo semver-checks check-release -p js-sandbox
    Updating index
     Parsing js-sandbox v0.2.0-rc.0 (current)
Error: Failed when running cargo-doc on <path>\js-sandbox\Cargo.toml: error: no such subcommand: `+nightly`

Expected Behaviour

Getting output about semver compatibility, or at least a logic-related error.

Additional Context

I tried with both cargo-semver-checks versions 0.9.1 and 0.9.2, same results.
I also tried alternative ways to invoke Cargo:

rustup run nightly cargo semver-checks check-release
    Updating index
     Parsing js-sandbox v0.2.0-rc.0 (current)
Error: Failed when running cargo-doc on <path>\js-sandbox\Cargo.toml: error: no such subcommand: `+nightly`

        Cargo does not handle `+toolchain` directives.
        Did you mean to invoke `cargo` through `rustup` instead?

It works when I run it on WSL2 (Linux) from the same Windows machine.

Debug Output

Software version

cargo-semver-checks 0.9.2

Operating system

Windows 6.2.9200

Command-line

C:\Users\<me>\.cargo\bin\cargo-semver-checks.exe semver-checks check-release -p js-sandbox --bugreport

cargo nightly version

> cargo +nightly -V
cargo 1.65.0-nightly (6da726708 2022-08-23)

Compile time information

• Profile: release
• Target triple: x86_64-pc-windows-msvc
• Family: windows
• OS: windows
• Architecture: x86_64
• Pointer width: 64
• Endian: little
• CPU features: fxsr,sse,sse2
• Host: x86_64-pc-windows-msvc

[epage]

rustup changed how it resolves things in 1.25.0 which broke a lot of programs. It reverted the change in 1.25.1 but it seems like some of the behavior is still lingering around on windows.

[epage]

Ah, looks like there is an issue: rust-lang/rustup#3036

[Bromeon]

Wow, thanks for the instant response! 🚀

That's unfortunate, but at least good to hear it's a known issue. Might then need to wait until rustup resolves this...

In the meantime, I might play around with the CI a bit. The GitHub Action seems to have no option to specify the base version, right? Let's say I'm working on v1.7 and want to check compatibility with v1.6, but v2.2 has already been released -- will that infer v1.7 from the current Cargo.toml and compare it automatically against the next-lower crates.io release? Or what's the behavior exactly?

[loafofpiecrust]

I also have this issue on Linux when installing rust directly through nix, since it doesn't involve rustup at all. Would it be possible to check if cargo is run through rustup before using the +nightly flag? I figure then I'll have to use nightly for my rust install, which is okay with me, not sure if that's an acceptable requirement for all non-rustup users.

[epage]

Another option is for us to switch to stable via RUSTC_BOOTSTRAP.