fix: clippy CI

[rudolfs]

As per workaround documented in: rust-lang/rust-clippy#4612

This adds 11m to the build however : (
We should probably try to upgrade to the latest nightly version and try -Zunstable-options.

Closes #376.

[xla]

A better way that doesn't increase the build time is to get rid of the check step, which is entailed in the clippy command. This would avoid the clean.

We should probably try to upgrade to the latest nightly version and try -Zunstable-options.

What you hope to gain from this? Or what will this impact?

[rudolfs]

A better way that doesn't increase the build time is to get rid of the check step, which is entailed in the clippy command. This would avoid the clean.

What does the check do and why do we need it in the first place?

What you hope to gain from this? Or what will this impact?

Apparently they fixed the bug and with that flag clippy should work and still use the cache. Read more about it here:
rust-lang/rust-clippy#3837 (comment)

[xla]

What does the check do and why do we need it in the first place?

It's the cargo builtin linter. clippy is a superset tho, so running either should be enough, In our case clippy preferrably.

Apparently they fixed the bug and with that flag clippy should work and still use the cache. Read more about it here:

Great, we run a reasonably recent nightly so the flag should be supported.

[rudolfs]

It's the cargo builtin linter. clippy is a superset tho, so running either should be enough, In our case clippy preferrably.

In that case I'll try to remove cargo check first and see if that gets clippy to work on CI again.

[rudolfs]

That seems to work and the build only takes 30s to fail on clippy.
Next step is fixing all the clippy complaints in this PR.

[xla]

That seems to work and the build only takes 30s to fail on clippy.

Glad my initial suggestion worked out. Let me know if you need help addressing the actual clippy complains.

[xla]

Would revert the unwrap change, otherwise gud.

🍭 🔁 🌒 🕒