cargo2junit will stop working with Rust 1.70

[jstarks]

The Rust libs team quietly decided to start blocking -Zunstable-options in Rust 1.70 outside of nightly builds. Rust 1.70 is now in beta.

rust-lang/rust#109044

$ cargo +beta test -- -Zunstable-options --format json
    Finished test [unoptimized + debuginfo] target(s) in 0.22s
     Running unittests src/lib.rs ([removed])
error: the option `Z` is only accepted on the nightly compiler
error: test failed, to rerun pass `--lib`

Arguably cargo2unit users were playing with fire by taking a dependency on this... but nonetheless this will strand users on 1.69 who depend on JSON output in their CI builds.

Luckily, it seems that setting RUSTC_BOOTSTRAP=1 in the environment before launching the test will work around this. This seems strictly worse than the status quo since it allows other Rust unstable features to be used as well. Oh well.

Perhaps the README should be updated to reflect this.

[mati865]

The Rust libs team quietly decided to start blocking -Zunstable-options in Rust 1.70 outside of nightly builds. Rust 1.70 is now in beta.

It's not like they did it for fun, they have fixed long standing issue that cargo2junit has been relying on:rust-lang/rust#75526
Sure it could been better announced but I think the author had not expected the fallout.

Note: I'm not a team member, just wasn't happy with tone of that message.

[jstarks]

The tone was intentional. They could have chosen any number of alternatives. They made the choice to break users.

[marmeladema]

For what it's worth, I have replaced cargo2junit with nextest with great success: https://nexte.st/book/junit.html

[aseure]

Thanks @marmeladema, I'll take a look.

[BratSinot]

The tone was intentional. They could have chosen any number of alternatives. They made the choice to break users.

You still can use RUSTC_BOOTSTRAP=1 cargo test with same result.

[infogulch]

This is the tracking issue for the unstable option --format json: rust-lang/rust#49359

[johnterickson]

Sorry for the radio silence - I'm a little confused here - does stable rust now have no structured logging for cargo test? I always knew it would break, but I had assumed it wouldn't break until it was replaced with something. I am open to suggestions.

[infogulch]

This project is using cargo2junit with the unstable option, which seems to work fine on 1.71:

https://github.com/mthom/scryer-prolog/blob/2e811de0f5b4ddc09a50660df50105ecdba7a9f6/.github/workflows/ci.yml#L63-L65

https://github.com/mthom/scryer-prolog/actions/runs/5859200266/job/15884709552

[detly]

does stable rust now have no structured logging for cargo test?

Correct.

I had assumed it wouldn't break until it was replaced with something

Incorrect 😉

To be fair to the devs, it wasn't so much "let's break this specific thing here even though there's no replacement", it was about closing an inconsistency with the command line arguments that incidentally affected this.

OTOH, a couple of them have been a bit derisive about the fact that people relied on this, even though it met a need that's fairly widespread but unmet by anything else official, and there's not a solid "laundry list" of things needed to get it stabilised (although there's this). Meanwhile, the real goal, jUnit XML output, seems fundamentally incompatible with libtest's current architecture (not in the sense it could never happen, but in that it could be a surprising amount of work to achieve).

I am open to suggestions.

(Suggestions from someone who has time to summarise this stuff because I already did it for colleagues anyway, but not time to actually help with the suggestions?)

• Straight up jUnit support seems much, much harder than stabilising the JSON format itself, so have a crack at the JSON stabilisation?
• Nextest might be a suitable replacement for a lot of people, you could suggest that as an easy path for current users and see what issues remain for anyone who doesn't migrate?

Either way, thanks for your work on this so far, it made adoption of Rust in an existing project that much more smooth.

[detly]

This project is using cargo2junit with the unstable option, which seems to work fine on 1.71:

This is using RUSTC_BOOTSTRAP=1 to enable unstable features, which is not practically different from just running cargo +nightly test ... -- -Z unstable-options --format json on the nightly toolchain matching your preferred stable version (except that you don't have to go hunting for which nightly toolchain matches your preferred stable version).

[infogulch]

Yes, thank you for clarifying.

Though I'd like to note that this project only does this on the specific call to cargo test, not any of the other cargo or rustc invocations in that pipeline. By that I mean it's possible to use this hacky workaround (tbf that's what it is) on just this cargo test invocation, without using it on any other invocations, including building. Whether that is a tolerable difference between build and test in your pipeline is up to you of course.