Skip to content

incr.comp.: Cache the specialization_graph query. #48987

Closed
@michaelwoerister

Description

@michaelwoerister

Computing the specialization graph for a trait involves looking at lots of things. The result of the query should be easily cacheable:

pub struct Graph {
// all impls have a parent; the "root" impls have as their parent the def_id
// of the trait
parent: DefIdMap<DefId>,
// the "root" impls are found by looking up the trait's def_id.
children: DefIdMap<Children>,
}
/// Children of a given impl, grouped into blanket/non-blanket varieties as is
/// done in `TraitDef`.
struct Children {
// Impls of a trait (or specializations of a given impl). To allow for
// quicker lookup, the impls are indexed by a simplified version of their
// `Self` type: impls with a simplifiable `Self` are stored in
// `nonblanket_impls` keyed by it, while all other impls are stored in
// `blanket_impls`.
//
// A similar division is used within `TraitDef`, but the lists there collect
// together *all* the impls for a trait, and are populated prior to building
// the specialization graph.
/// Impls of the trait.
nonblanket_impls: FxHashMap<fast_reject::SimplifiedType, Vec<DefId>>,
/// Blanket impls associated with the trait.
blanket_impls: Vec<DefId>,
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-incr-compArea: Incremental compilationE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.I-compiletimeIssue: Problems and improvements with respect to compile times.WG-compiler-performanceWorking group: Compiler Performance

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions