Ignore receiver_waker_size test since it's unstable

[faern]

At first I just updated the sizes to match stable Rust 1.84. But I then realized the size of Thread was smaller again on nightly. So let's ignore the test for now and see what the standard library settles on, if anything stable at all. The standard library give no size guarantees about the struct we are testing the size of, so this test is inherently unstable! The problem lies in this library, not in std. I just want to have this test in place to catch library bugs that cause the ReceiverWaker to blow up in size unintentionally.

The Rust PR that reverted the size increase of std::thread::Thread, and made it go back to pre Rust 1.84 sizes is this one: rust-lang/rust#132654

[faern]

So annoying that to run cargo test the benchmarking-only dependencies need to be built. And they in turn has a much higher MSRV than this library. Dev dependencies also can't be optional, so I can't run tests without criterion 🤷 🙃

Will work around this by simply not running the tests on the MSRV version of Rust for this library. Verifying it via just cargo build will have to do 😢

[ada4a]

So annoying that to run cargo test the benchmarking-only dependencies need to be built. And they in turn has a much higher MSRV than this library. Dev dependencies also can't be optional, so I can't run tests without criterion 🤷 🙃

Couldn't you do something like this?

[target.'cfg(not(test))'.dev-dependencies]
criterion = "0.5.1"

[faern]

That is sadly not possible. Quoting https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

The same applies to cfg(debug_assertions), cfg(test) and cfg(proc_macro). These values will not work as expected and will always have the default value returned by rustc --print=cfg. There is currently no way to add dependencies based on these configuration values.

[faern]

But I solved it with a hack similar to the loom stuff: A custom cfg. This hurts the developer experience for the benchmarks, since and it requires running benches in an awkward way, but at least it builds and runs.

I should note that Rust 1.65 is very old! And I'm by no means a strict MSRV advocate. I'd happily be supporting current - 2 or similar as my MSRV policy. It just irritates me that cargo handles this so clumsy. That benchmarking dependencies mess with the support possibilities of the main library.

[faern]

I moved the criterion over to #54, to not mix different tasks up in one PR. Now this very simple ignore-PR can pass cleanly.