>The most frustrating part of using Clippy is that it did not force a reanalysis of all packages in my cargo workspace when invoked multiple times.
This is because the author used `#[warn(clippy::all)]` instead of `#[deny]`. Warnings do not fail the build, so subsequent rebuilds will be no-ops. If you're at the stage where you've fixed regular compilation errors and are only fixing clippy lints, you should probably change that to `#[deny]`. (I personally keep it at `#[deny]` from the start.) Or run clippy as `cargo clippy -- -Dwarnings` to treat warnings as errors.
>Linking to code units in rustdoc was hard to do correctly since there were so many ways to do it.
If you're planning to publish the crate to crates.io and are okay with relying on docs.rs to host the docs, then you can rely on the fact that docs.rs uses a nightly rustdoc and use nightly-rustdoc-specific features. Specifically you can use
[`Foo`]
to create a link to whatever `Foo` happens to be in the code scope.
>My one complaint is that `RUST_LOG=debug cargo run` dumps all of the verbose debug logs from cargo while your program is being built.
You would use the env_logger builder to parse a different env var like "PUNCHTOP_LOG", instead of the default "RUST_LOG".
Thank you for the suggestions and code review via blog post ;)
You are correct that `#[deny]` is what I want with Clippy.
The env_logger builder is something I didn't know about. The homepage for the docs does not even mention it - https://docs.rs/env_logger/0.6.0/env_logger/. I agree that I should depend on my own env variable, but should cargo not do the same?
Well cargo and rustc are both first-party Rust tools, so it's expected that they would use "RUST_LOG". I have wondered why env_logger defaults to using it instead of requiring you to specify which env var you want to parse, but it is what it is.
No, it is not: it is a drinking game (as the Wikipedia page linked by the author clearly states). Music is only incidentally used to mark the passing of time: a timer works just as well.
>The most frustrating part of using Clippy is that it did not force a reanalysis of all packages in my cargo workspace when invoked multiple times.
This is because the author used `#[warn(clippy::all)]` instead of `#[deny]`. Warnings do not fail the build, so subsequent rebuilds will be no-ops. If you're at the stage where you've fixed regular compilation errors and are only fixing clippy lints, you should probably change that to `#[deny]`. (I personally keep it at `#[deny]` from the start.) Or run clippy as `cargo clippy -- -Dwarnings` to treat warnings as errors.
>Linking to code units in rustdoc was hard to do correctly since there were so many ways to do it.
If you're planning to publish the crate to crates.io and are okay with relying on docs.rs to host the docs, then you can rely on the fact that docs.rs uses a nightly rustdoc and use nightly-rustdoc-specific features. Specifically you can use
to create a link to whatever `Foo` happens to be in the code scope.>My one complaint is that `RUST_LOG=debug cargo run` dumps all of the verbose debug logs from cargo while your program is being built.
You would use the env_logger builder to parse a different env var like "PUNCHTOP_LOG", instead of the default "RUST_LOG".
Thank you for the suggestions and code review via blog post ;)
You are correct that `#[deny]` is what I want with Clippy.
The env_logger builder is something I didn't know about. The homepage for the docs does not even mention it - https://docs.rs/env_logger/0.6.0/env_logger/. I agree that I should depend on my own env variable, but should cargo not do the same?
Well cargo and rustc are both first-party Rust tools, so it's expected that they would use "RUST_LOG". I have wondered why env_logger defaults to using it instead of requiring you to specify which env var you want to parse, but it is what it is.
Thank you for sharing your knowledge with me Arnavion. I've applied what I've learned here: https://github.com/lopopolo/punchtop/pull/1
:)
You can also just scope the RUST_LOG to your crate's modules: RUST_LOG="punchtop=debug". Done!
True, but when you ship your application you probably want to use your own env var anyway, instead of piggy-backing on "RUST_LOG".
Or you can write a bash script to touch all your *.rs files, and then you can see the warnings fresh.
I'm not a huge fan of that that behavior, but I think it matches how gcc and other compilers behave.
There is work being done now to improve this situation for clippy.
https://github.com/rust-lang/rust-clippy/issues/2604
"Punchtop is an audio game"
No, it is not: it is a drinking game (as the Wikipedia page linked by the author clearly states). Music is only incidentally used to mark the passing of time: a timer works just as well.
Here is what is usually meant by "audio game": https://en.wikipedia.org/wiki/Audio_game