chore: ci: run `cargo check` and clippy for all targets

[istankovic]

Here targets refer to cargo targets: binaries, tests, benches etc.

[github-actions[bot]]

Bencher Report

Branch	ivan/check-all-targets
Testbed	ubuntu-latest

Click to view all benchmark results

Benchmark	Latency	milliseconds (ms)
Commit add f(group size)/cs1/mem/1002	📈 view plot 🚷 view threshold	19.98 ms
Commit add f(group size)/cs1/mem/2	📈 view plot 🚷 view threshold	5.25 ms
Commit add f(group size)/cs1/mem/202	📈 view plot 🚷 view threshold	8.62 ms
Commit add f(group size)/cs1/mem/402	📈 view plot 🚷 view threshold	11.46 ms
Commit add f(group size)/cs1/mem/602	📈 view plot 🚷 view threshold	14.96 ms
Commit add f(group size)/cs1/mem/802	📈 view plot 🚷 view threshold	17.81 ms
Commit add f(number clients)/cs1/mem/1002	📈 view plot 🚷 view threshold	994.32 ms
Commit add f(number clients)/cs1/mem/2	📈 view plot 🚷 view threshold	5.31 ms
Commit add f(number clients)/cs1/mem/202	📈 view plot 🚷 view threshold	84.78 ms
Commit add f(number clients)/cs1/mem/402	📈 view plot 🚷 view threshold	223.23 ms
Commit add f(number clients)/cs1/mem/602	📈 view plot 🚷 view threshold	432.85 ms
Commit add f(number clients)/cs1/mem/802	📈 view plot 🚷 view threshold	689.00 ms
Commit pending proposals f(group size)/cs1/mem/1002	📈 view plot 🚷 view threshold	119.77 ms
Commit pending proposals f(group size)/cs1/mem/2	📈 view plot 🚷 view threshold	27.35 ms
Commit pending proposals f(group size)/cs1/mem/202	📈 view plot 🚷 view threshold	46.02 ms
Commit pending proposals f(group size)/cs1/mem/402	📈 view plot 🚷 view threshold	61.73 ms
Commit pending proposals f(group size)/cs1/mem/602	📈 view plot 🚷 view threshold	81.21 ms
Commit pending proposals f(group size)/cs1/mem/802	📈 view plot 🚷 view threshold	96.95 ms
Commit pending proposals f(pending size)/cs1/mem/1	📈 view plot 🚷 view threshold	19.81 ms
Commit pending proposals f(pending size)/cs1/mem/101	📈 view plot 🚷 view threshold	118.36 ms
Commit pending proposals f(pending size)/cs1/mem/21	📈 view plot 🚷 view threshold	37.00 ms
Commit pending proposals f(pending size)/cs1/mem/41	📈 view plot 🚷 view threshold	58.90 ms
Commit pending proposals f(pending size)/cs1/mem/61	📈 view plot 🚷 view threshold	78.05 ms
Commit pending proposals f(pending size)/cs1/mem/81	📈 view plot 🚷 view threshold	98.20 ms
Commit remove f(group size)/cs1/mem/1002	📈 view plot 🚷 view threshold	27.02 ms
Commit remove f(group size)/cs1/mem/2	📈 view plot 🚷 view threshold	5.26 ms
Commit remove f(group size)/cs1/mem/202	📈 view plot 🚷 view threshold	7.45 ms
Commit remove f(group size)/cs1/mem/402	📈 view plot 🚷 view threshold	10.59 ms
Commit remove f(group size)/cs1/mem/602	📈 view plot 🚷 view threshold	15.95 ms
Commit remove f(group size)/cs1/mem/802	📈 view plot 🚷 view threshold	20.45 ms
Commit remove f(number clients)/cs1/mem/1002	📈 view plot 🚷 view threshold	29.13 ms
Commit remove f(number clients)/cs1/mem/2	📈 view plot 🚷 view threshold	139.09 ms
Commit remove f(number clients)/cs1/mem/202	📈 view plot 🚷 view threshold	116.22 ms
Commit remove f(number clients)/cs1/mem/402	📈 view plot 🚷 view threshold	93.25 ms
Commit remove f(number clients)/cs1/mem/602	📈 view plot 🚷 view threshold	71.67 ms
Commit remove f(number clients)/cs1/mem/802	📈 view plot 🚷 view threshold	49.95 ms
Commit update f(group size)/cs1/mem/1002	📈 view plot 🚷 view threshold	139.53 ms
Commit update f(group size)/cs1/mem/2	📈 view plot 🚷 view threshold	5.42 ms
Commit update f(group size)/cs1/mem/202	📈 view plot 🚷 view threshold	32.57 ms
Commit update f(group size)/cs1/mem/402	📈 view plot 🚷 view threshold	59.31 ms
Commit update f(group size)/cs1/mem/602	📈 view plot 🚷 view threshold	86.94 ms
Commit update f(group size)/cs1/mem/802	📈 view plot 🚷 view threshold	112.75 ms

🐰 View full continuous benchmarking report in Bencher

[github-actions[bot]]

Bencher Report

Branch	ivan/check-all-targets
Testbed	ubuntu-latest

Click to view all benchmark results

Benchmark	Latency	milliseconds (ms)
decrypt1000MessagesWeb	📈 view plot 🚷 view threshold	426.50 ms

🐰 View full continuous benchmarking report in Bencher

[istankovic]

I don't think that eliminating black_box calls from the benches is the right strategy. It feels like exactly the kind of hinting you want for a good benchmark. https://doc.rust-lang.org/beta/std/hint/fn.black_box.html

For this particular case, I do not think that calls to black_box were done in any systematic or meaningful way. (If someone knows more about the way it was done, I'd be happy to know!)

For instance, what should

black_box(());

actually do?

Not only that, but a thing like

black_box(foo(....)));

where foo() returns a unit value seems unnecessary, especially when you consider the fact that arguments are evaluated eagerly. Honestly, without a proper reasoning why this actually helps, this feels more like cargo culting.

[coriolinus]

Sure, passing a literal unit struct is probably pointless. I don't mind stripping those instances.

black_box(foo(....)));

This does feel helpful, to me. The documentation linked above has a whole section called When is this useful?. It's a compiler hint aimed at avoiding the compiler deciding "foo has no effects observable from the outside, so no point calling it here at all.

this feels more like cargo culting.

I mean, that's kind of fair. I have not attempted to understand the actual set of optimizations that LLVM applies to an arbitrary piece of Rust code, and can't prove that the black box is helpful in this case.

On the other hand, what we have here is a compiler hint intended for benchmarking, being used in the documented way in some benchmarks. We can only really prove it's useful if by removing it our benchmarks suddenly get much faster, because they're no longer measuring anything. But that might only happen at some point in the future when the compiler optimizer changes without our notice. Seems safer to leave it in place.

[istankovic]

I mean, that's kind of fair. I have not attempted to understand the actual set of optimizations that LLVM applies to an arbitrary piece of Rust code, and can't prove that the black box is helpful in this case.

On the other hand, what we have here is a compiler hint intended for benchmarking, being used in the documented way in some benchmarks. We can only really prove it's useful if by removing it our benchmarks suddenly get much faster, because they're no longer measuring anything. But that might only happen at some point in the future when the compiler optimizer changes without our notice. Seems safer to leave it in place.

Fair. I've added allow attributes in cases where a non-literal unit is passed, and removed the rest.