LukasKalbertodt / libtest-mimic

A small test framework to write your own test harness that looks and behaves like the built-in test harness used by `rustc --test`
https://docs.rs/libtest-mimic
Apache License 2.0
105 stars 30 forks source link

MSRV of 1.65 is broken #49

Open epage opened 4 weeks ago

epage commented 4 weeks ago

To reproduce, I had to do:

$ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback cargo +nightly generate-lockfile
$ cargo +1.65 check
error[E0277]: `Sender<(Outcome, TestInfo)>` cannot be shared between threads safely
   --> src/lib.rs:521:29
    |
521 |                   scope.spawn(|| {
    |  _______________________-----_^
    | |                       |
    | |                       required by a bound introduced by this call
522 | |                     loop {
523 | |                         // Get next test to process from the iterator.
524 | |                         let Some(trial) = iter.lock().unwrap().next() else {
...   |
539 | |                     }
540 | |                 });
    | |_________________^ `Sender<(Outcome, TestInfo)>` cannot be shared between threads safely
    |
    = help: the trait `Sync` is not implemented for `Sender<(Outcome, TestInfo)>`
    = note: required for `&Sender<(Outcome, TestInfo)>` to implement `Send`
note: required because it's used within this closure
   --> src/lib.rs:521:29
    |
521 |                 scope.spawn(|| {
    |                             ^^
note: required by a bound in `Scope::<'scope, 'env>::spawn`

Not seeing any MSRV verification in CI. Highly recommend cargo hack for this as it let's you single-source your MSRV, e.g. https://github.com/epage/_rust/blob/e121dd6ef9e11dfa818a813bbaffb12a16cd174e/.github/workflows/ci.yml#L54-L67

LukasKalbertodt commented 3 weeks ago

Hi, thanks for the ping. So there is https://github.com/LukasKalbertodt/libtest-mimic/commit/08e76d3557ea7e4ebfac403574eeb6f5a17f49a4 from some time ago, where I removed the MSRV CI check since it broke due to a new clap version. As you can see in the commit message, I don't really know how I, as a library maintainer, should deal with this. Do I simply state the MSRV of my code without dependencies? Do I state the MSRV of my code and of the oldest supported versions of my dependencies (which, in case of that commit, would be clap 4.0.x)? Because tracking the MSRV of the newest versions of all of my dependencies, that seems like exhausting and annoying work.

I suppose that Cargo can chose compatible dependency versions, also considering rust-version. I'm not sure if that was already the case when I created that commit. I do know that CI just broke due to a new clap version.

So yeah: can you tell me about best practices?

(Note: cargo hack seems really cool, not only for MSRV. I didn't know that, thanks!)

epage commented 3 weeks ago

While not yet on the stable version of the Cargo book, the Cargo team has posted guidance on MSRV that includes this topic, see https://doc.rust-lang.org/nightly/cargo/reference/rust-version.html#support-expectations

For myself, I have a Cargo.lock committed that is compatible with my MSRV. You can jump start that on nightly using the MSRV-aware resolver, see https://doc.rust-lang.org/nightly/cargo/reference/config.html#resolverincompatible-rust-versions