Safe Build Guidance

[bradlitterell]

Since one of the primary reasons to create a Rust-based TPM implementation is to leverage Rust's safety features, I think it makes sense that we leverage as much error checking as possible in the build.

Thus, I propose the core implementation of tpm-rs be as portable and safe as possible by liberal application of #!deny and clippy.

I look to the real Rust experts to suggest specific clippy settings we should adopt, but at least I suggest we start with these:

#![forbid(unsafe_code)]
#![deny(warnings)]
#![deny(clippy::all)]

and use #![no_std] and no_alloc as well (thanks @chrisfenner for these suggestions).

notes:

1. My understanding is that #![deny(clippy::all)] does not enforce every possible warning in clippy, but just the defaults.
2. Also, I would suggest #![forbid(warnings)] to disable re-allowing all warnings by default, so long as it is still possible for a particular bit of code to allow a particular individual warning if necessary.

Any thoughts or objections, anything else?

[daprilik]

Two thoughts:

---

deny(some_big_lint_group) is typically a bad idea, as per https://github.com/rust-unofficial/patterns/blob/main/src/anti_patterns/deny-warnings.md.

Moreover, it makes local development a real PITA, as when you're just hacking on changes, having to keep your local fork lint-clean 100% of the time is a real hassle.

As per the advice in the link, it'd be better to configure the lints via warn(..), and then pass -D warnings when building in CI.

---

clippy::all is a real grab-bag of lints - both high quality, and not so high quality...

I would suggest basing lints off some existing curated lint list (e.g: https://github.com/EmbarkStudios/rust-ecosystem/blob/main/lints.toml), while also fine-tuning it to the specifics of the tpm-rs project

[kupiakos]

The difference between forbid and deny is whether you're allowed to allow that lint.

#![no_std]

I would suggest #![cfg_attr(not(test), no_std)] to make it easier to write unit tests. The code does this currently.

no_alloc

You don't need to write no_alloc anywhere: just don't import anything that uses alloc.

forbid(unsafe_code)

That would require unsafe into isolated crates, which we can do. deny(unsafe_code) lets you still allow in specific locations. In the crates where we allow unsafe code, we should also write #![deny(unsafe_op_in_unsafe_fn)].

I'm supportive of adding the forbid lint, though its usefulness is reduce by the only current unsafe being macro-generated, which this lint won't catch.

I also generally agree with @daprilik on deny(warnings) and deny(clippy:all).