Struct Metadata

pub struct Metadata {
    unit_id: UnitHash,
    c_metadata: UnitHash,
    c_extra_filename: Option<UnitHash>,
}

Metadata tracks several UnitHashs, including Metadata::unit_id, Metadata::c_metadata, and Metadata::c_extra_filename.

We use a hash because it is an easy way to guarantee that all the inputs can be converted to a valid path.

Metadata::unit_id is used to uniquely identify a unit in the build graph. This serves as a similar role as Metadata::c_extra_filename in that it uniquely identifies output on the filesystem except that its always present.

Metadata::c_extra_filename is needed for cases like:

• A project may depend on crate A and crate B, so the package name must be in the file name.
• Similarly a project may depend on two versions of A, so the version must be in the file name.

This also acts as the main layer of caching provided by Cargo so this must include all things that need to be distinguished in different parts of the same build. This is absolutely required or we override things before we get chance to use them.

For example, we want to cache cargo build and cargo doc separately, so that running one does not invalidate the artifacts for the other. We do this by including CompileMode in the hash, thus the artifacts go in different folders and do not override each other. If we don’t add something that we should have, for this reason, we get the correct output but rebuild more than is needed.

Some things that need to be tracked to ensure the correct output should definitely not go in the Metadata. For example, the modification time of a file, should be tracked to make a rebuild when the file changes. However, it would be wasteful to include in the Metadata. The old artifacts are never going to be needed again. We can save space by just overwriting them. If we add something that we should not have, for this reason, we get the correct output but take more space than needed. This makes not including something in Metadata a form of cache invalidation.

Note that the Fingerprint is in charge of tracking everything needed to determine if a rebuild is needed.

Metadata::c_metadata is used for symbol mangling, because if you have two versions of the same crate linked together, their symbols need to be differentiated.

You should avoid anything that would interfere with reproducible builds. For example, any absolute path should be avoided. This is one reason that RUSTFLAGS is not in Metadata::c_metadata, because it often has absolute paths (like --remap-path-prefix which is fundamentally used for reproducible builds and has absolute paths in it). Also, in some cases the mangled symbols need to be stable between different builds with different settings. For example, profile-guided optimizations need to swap RUSTFLAGS between runs, but needs to keep the same symbol names.

Fields

unit_id: UnitHash

c_metadata: UnitHash

c_extra_filename: Option<UnitHash>

Implementations

impl Metadata

pub fn unit_id(&self) -> UnitHash

A hash to identify a given Unit in the build graph

pub fn c_metadata(&self) -> UnitHash

A hash to add to symbol naming through -C metadata

pub fn c_extra_filename(&self) -> Option<UnitHash>

A hash to add to file names through -C extra-filename

Trait Implementations

impl Clone for Metadata

fn clone(&self) -> Metadata

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Metadata

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Copy for Metadata

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 32 bytes