Add a phase that removes ResolvedTypeRefs before codegen

[fitzgen]

Ever since we got the graphviz visualizations of our IR graph, it has become immediately clear that we have a TON of ResolvedTypeRefs all over the place. In fact, 8 out of 15 IR items (more than half!) are ResolvedTypeRefs in this example I happen to be looking at:

A pass over the IR items where we replace all references to ResolvedTypeRefs with references to the type being transitively referenced via the ResolvedTypeRef would probably give us speed ups in codegen and analysis, because we wouldn't have to look at useless items anymore. It would also make looking at these graphs easier, since there would be less visual noise :-P

A good time to do this would be in ir::context::BindgenContext::gen, after we resolve unresolved type refs in resolve_typerefs. https://github.com/servo/rust-bindgen/blob/master/src/ir/context.rs#L529

I can mentor whoever would like to take a stab at this.

[fitzgen]

If you want to pick this up, leave a comment and I can assign you :)

[samliu]

Hey Nick! (How are you?!) I've been learning Rust and this looks really interesting. I'd be down to take a stab :)

[fitzgen]

Great! Let me know if you have any questions or anything like that.

I just realized that fully removing ResolvedTypeRefs would require modifying ir::traversal::Trace to be generic over either &mut ItemId edges or just ItemIds like it is now. This is a bit more tricky than I anticipated, and so I think we should resign ourselves to flattening ResolvedTypeRef chains to a single ResolvedTypeRef. That is,

ResolvedTypeRef -> ResolvedTypeRef -> ResolvedTypeRef -> SomeType

should become:

ResolvedTypeRef -> SomeType

The core of this new phase should look something like this pseudo code:

impl BindgenContext {
    // ...

    fn flatten_resolved_type_ref(&mut self) {
        for (id, item) in self.items {
            if item is a resolved type ref {
                self.flatten_one_resolved_type_ref(id);
            }
        }
    }

    // Recursively walk the chain of ResolvedTypeRefs and flatten it as we
    // come back out of the recursion.
    fn flatten_one_resolved_type_ref(&mut self, id: ItemId) -> ItemId { 
        if id's item is a resolved type ref {
            let final_referenced_id = self.flatten_one_resolved_type_ref(item's referenced type);
            item's referenced type = final_referenced_id;
            final_referenced_id
        } else {
            id
        }
    }

    // ...
}

Bonus points for keeping a debug-only set of items we've walked in the recursive function and asserting that we don't get a cycle :) See https://github.com/servo/rust-bindgen/blob/master/src/ir/item.rs#L69-L87

[fitzgen]

(Also, woah! Hey! Didn't read your username very carefully, at first! :-P)

[emilio]

I have an issue with this, and is that this would lose the constness information, which we do use for code generation.

[fitzgen]

I have an issue with this, and is that this would lose the constness information, which we do use for code generation.

Crap, I forgot about that. It would be great if we separated the concept of a resolved type reference from a const <type>, then we could move forward here.

@samliu interested in this prerequisite groundwork?

[samliu]

Definitely!

…

On Feb 22, 2017 7:44 AM, "Nick Fitzgerald" ***@***.***> wrote: I have an issue with this, and is that this would lose the constness information, which we do use for code generation. Crap, I forgot about that. It would be great if we separated the concept of a resolved type reference from a const <type>, then we could move forward here. @samliu <https://github.com/samliu> interested in this prerequisite groundwork? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#534 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIS_T9m-04rdhW-glpN8zWbTZbxX0e6ks5rfFf1gaJpZM4MHk79> .

[emilio]

As an idea, we probably want to call this something like QualifiedType,
and it'd be something like:

struct Qualifiers {
    is_const: bool,
}

struct QualifiedType {
    ty: ItemId,
    qualifiers: Qualifiers,
}

[fitzgen]

Yep, exactly what I was imagining!

It will also need to be Traced from the impl Trace for Type as well (either directly there, or as a second Trace implementation that is called from there).

[fitzgen]

(And there would be a new TypeKind variant called TypeKind::Qualified(QualifiedType) or something)

[emilio]

(And there would be a new TypeKind variant called TypeKind::Qualified(QualifiedType) or something)

Why would that be needed? We only care about qualifiers in top-level types, right?

I.e., const StructName* foo; would be a TypeKind::Pointer(QualifiedType), and so on with fields, arrays, etc.

Am I missing something?

[emilio]

Why would that be needed? We only care about qualifiers in top-level types, right?

With top-level types, I mean in the stuff that holds from TypeKind, Var, etc.