Audit metadata dep-graph edges

[nikomatsakis]

When we record the metadata, we create a new task for the metadata pertaining to each item. The incoming edges to this task are then used to compute the hash of the metadata. This is all good, but there are a number of cases of "information leaks" that will lead to missing edges.

One example:

fn encode_info_for_method<'a, 'tcx>(ecx: &EncodeContext<'a, 'tcx>,
                                    rbml_w: &mut Encoder,
                                    index: &mut CrateIndex<'a, 'tcx>,
                                    m: &ty::Method<'tcx>,
                                    is_default_impl: bool,
                                    parent_id: NodeId,
                                    impl_item_opt: Option<&hir::ImplItem>) {

    debug!("encode_info_for_method: {:?} {:?}", m.def_id,
           m.name);
    let _task = index.record(m.def_id, rbml_w); // creates a task X

Here, if the function reads from m or impl_item_opt, this will not result in any incoming edges to the task X. To make this correct, we should either add artificial, explicit reads to account for those parameters or -- probably better -- minimize the data we pass in, and have encode_info_for_method go fetch things out of the appropriate maps, which will register the proper reads.

[michaelwoerister]

So, if we used TyCtxt::visit_all_items_in_krate() instead of Crate::visit_all_items() at

rust/src/librustc_metadata/encoder.rs

Line 1417 in 5a7773a

krate.visit_all_items(&mut EncodeVisitor {

, that would fix the majority of problems, right?

[nikomatsakis]

@michaelwoerister yeah, actually, I think that was a mistake on my part. That would certainly be a good step. :) Probably ought to change the names there to make the distinction more obvious.

[nikomatsakis]

I'll tackle this.

[michaelwoerister]

It would also be good to see if we are reading data from external crates that is not linked to a specific DefId (i.e. "global" data like the disambiguator) but still influences codegen in some way.