This doc defines some guidelines for developing Teaclave in Rust.
clippy to format and lint all Rust code. Mostly, we use the default configurations, but there are a couple of custom settings and lint exceptions. The exceptions should be defined along with the code. Our CI will check the format/lint issues and deny all warnings by default. Simply run
make format to format all code and
make CLP=1 to lint code before submitting a PR. If you still have some doubts of the
clippy error, feel free to point out and add an exception.
Elegantly designed functions and APIs will make the project readable and user-friendly. Basically, we follow naming conventions and API design patterns of Rust standard library. There's no official guideline, but here are several articles or docs for reference:
Using unsafe Rust is extremely dangerous, and may break Rust's strong memory-safety guarantees. Therefore, we want to keep unsafe Rust as minimal as possible. Sometimes (very rare) using unsafe Rust can significantly improve performance, the unsafe code should be well documented and explain the rationales. For contributors and reviewers, pay attention to the unsafe code and carefully check whether the pre-conditions and post-conditions still hold.
expect to get a value from an optional type may introduce runtime panic. Therefore, properly using the error handling mechanism provided by Rust can make the system robust and clean. In some cases, optional value can never be
unwrap can be used with a comment explaining the assumptions and reasons. The same rule also applies to
panic and similar functions which may cause runtime panic. One exception is to use
expect in tests, while
expect is better because it will show a message to help debugging.
To ensure the security, stability and compatibility of upstream crates, all third-party crates (especially for ported SGX-compatible crates) used in Teaclave are vendored in the
third_party directory. Please refer to the
crates-io repo and choose specific versions of vendored crates.