Struct rustc_middle::dep_graph::WorkProduct

pub struct WorkProduct {
    pub cgu_name: String,
    pub saved_files: UnordMap<String, String>,
}

A “work product” is an intermediate result that we save into the incremental directory for later re-use. The primary example are the object files that we save for each partition at code generation time.

Each work product is associated with a dep-node, representing the process that produced the work-product. If that dep-node is found to be dirty when we load up, then we will delete the work-product at load time. If the work-product is found to be clean, then we will keep a record in the previous_work_products list.

In addition, work products have an associated hash. This hash is an extra hash that can be used to decide if the work-product from a previous compilation can be re-used (in addition to the dirty edges check).

As the primary example, consider the object files we generate for each partition. In the first run, we create partitions based on the symbols that need to be compiled. For each partition P, we hash the symbols in P and create a WorkProduct record associated with DepNode::CodegenUnit(P); the hash is the set of symbols in P.

The next time we compile, if the DepNode::CodegenUnit(P) is judged to be clean (which means none of the things we read to generate the partition were found to be dirty), it will be loaded into previous work products. We will then regenerate the set of symbols in the partition P and hash them (note that new symbols may be added – for example, new monomorphizations – even if nothing in P changed!). We will compare that hash against the previous hash. If it matches up, we can reuse the object file.

Fields

cgu_name: String

saved_files: UnordMap<String, String>

Saved files associated with this CGU. In each key/value pair, the value is the path to the saved file and the key is some identifier for the type of file being saved.

By convention, file extensions are currently used as identifiers, i.e. the key “o” maps to the object file’s path, and “dwo” to the dwarf object file’s path.

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: 56 bytes