Rust is a systems programming language designed for safety, speed, and concurrency. Rust has numerous compile-time features and safety checks to avoid data races and common bugs, all with minimal to zero runtime overhead.
A walkthrough of macros can be found in The Rust Programming Language (a.k.a. The Book).
cargo bench
subcommand requires the nightly version of the compiler to operate effectively.When deconstructing a structure value, the field should be either of the form field_name
or field_name: pattern
. If no pattern is specified, an implicit binding is done:
let Point { x, y } = p; // equivalent to let Point { x: x, y: y } = p; let Point { ref x, ref y } = p; // equivalent to let Point { x: ref x, y: ref y } = p;
1: Irrefutable pattern
const
values are always inlined and have no address in memory.static
values are never inlined and have one instance with a fixed address.static mut
values are not memory safe and thus can only be accessed in an unsafe
block.lazy_static
objects are immutable, are initialized only once, are shared among all threads, and can be directly accessed (there are no wrapper types involved). In contrast, thread_local
objects are meant to be mutable, are initialized once for each thread, and accesses are indirect (involving the wrapper type LocalKey<T>
)Details of error handling is described in The Rust Programming Language (a.k.a The Book)
'static
lifetime is assigned to references that are stored in the program binary and will be valid throughout its entire execution. This lifetime is most notably assigned to string literals, which have the type &'static str
.AsRef
and Borrow
are similar but serve distinct purposes. Borrow
is used to treat multiple borrowing methods similarly, or to treat borrowed values like their owned counterparts, while AsRef
is used for genericizing references.From<A> for B
implies Into<B> for A
, but not vice-versa.From<A> for A
is implicitly implemented.Rust doesn't have a proper and idiomatic and safe way to lydiate with OS signals but there are some crates that provide signal handling but they are highly experimental and unsafe so be careful when using them.
However there is a discussion in the rust-lang/rfcs repository about implementing native signal handling for rust.
RFCs discussion: https://github.com/rust-lang/rfcs/issues/1368
~
. You may see this in very old examples.The official Rust style guidelines were available in the rust-lang/rust
repository on GitHub, but they have recently been removed, pending migration to the rust-lang-nursery/fmt-rfcs
repository. Until new guidelines are published there, you should try to follow the guidelines in the rust-lang
repository.
You can use rustfmt and clippy to automatically review your code for style issues and format it correctly. These tools can be installed using Cargo, like so:
cargo install clippy
cargo install rustfmt
To run them, you use:
cargo clippy
cargo fmt
This section of the 'Rust Book' may contain useful information about documentation and documentation tests.
Documentation comments can be applied to:
Panics don't always cause memory leaks or other resource leaks. In fact, panics typically preserve RAII invariants, running the destructors (Drop implementations) of structs as the stack unwinds. However, if there is a second panic during this process, the program simply aborts; at that point, RAII invariant guarantees are void.
This feature is currently available only in nightly compiler. Tracking issue #29646
Using the Drop Trait does not mean that it will be run every time. While it will run when going out of scope or unwinding, it might not not always be the case, for example when mem::forget
is called.
This is because a panic while unwinding causes the program to abort. It also might have been compiled with Abort on Panic
switched on.
For more information check out the book: https://doc.rust-lang.org/book/drop.html
&my_object
where the type of my_object
is T) will coerce to *const T
. Similarly, mutable references coerce to *mut T
.There is built-in support for a RNG associated with each thread stored in thread-local storage. This RNG can be accessed via thread_rng
, or used implicitly via random
. This RNG is normally randomly seeded from an operating-system source of randomness, e.g. /dev/urandom
on Unix systems, and will automatically reseed itself from this source after generating 32 KiB of random data.
An application that requires an entropy source for cryptographic purposes must use OsRng
, which reads randomness from the source that the operating system provides (e.g. /dev/urandom
on Unixes or CryptGenRandom()
on Windows). The other random number generators provided by this module are not suitable for such purposes.