Add a debug phase to assert against dangling ItemId references without an associated Item

[fitzgen]

We should traverse the Item graph and ensure that for every ItemId reference an Item has, there is an entry in BindgenContext::items for that ItemId. If there isn't then it is a dangling reference, codegen will blow up, and we did something wrong in parsing.

Bonus points if the graph traversal is BFS and we can dump to stdout the shortest path to the dangling reference.

We can do this in a conservative manner with the TypeCollector trait, but to get precise results that consider all ItemId references, we'll need a similar trait for all Items, not just Items that are Types (which is what TypeCollector is).

[fitzgen]

FWIW, I've been debugging dangling references in codegen, and it requires rr to get anywhere. If we had this assertion phase, I think it would be easier to debug.

[impowski]

I could take it because it will be interesting to play around graphs. As always some sneak peak where to start and potential problems.

[fitzgen]

Great :)

Here is a modest / version 0 / MVP approach that doesn't do a full shortest path to the dangling reference, nor finds all inter item references (just those exposed by TypeCollector implementations):

This phase should happen after parsing, just before code generation. Maybe called directly from BindgenContext::gen? It would iterate over items in the context, call TypeCollector::collect_types on each item, and for each sub-item assert that the context has the sub-item (ie it is not a dangling ItemId reference).

Here's a sketch:

for (id, item) in ctx.items() {
    let mut sub_items = ItemSet::new();
    item.collect_types(ctx, &mut sub_items, &());

    sub_items.insert(item.parent_id());

    for sub in sub_items {
        assert!(ctx.fallible_resolve_item(sub).is_some(),
               "Should not dangle: {:?} references {:?}", id, sub);
    }
}

[fitzgen]

Fixed in #312