This seems insufficiently general. In particular, I think you can have things like &Foo<Bar<T>> to &Foo<Bar<Trait>>, which will be overlooked here. I'm not sure what's the best way to drill down into the "core operations", I'll have to go look at that code again. @eddyb may remember. There is hopefully a helper fn that can give you what you want.
This is where we need the table, obviously. Can we restruture this code so that instead of assuming that every fn has a node-id, it assumes things have def-ids? For example, we could convert the MirMap into a DefIdMap. Then we can load the MIR for the def-id. Think about it and let me know what you think. :)
DRY.. Or, perhaps better yet, just refactored into a common subroutine. See other DRY comments below.
Nit. not valid markdown :)
Nit. I think maybe by "then &SomeStruct is a thin pointer", you meant &ComplexStruct<T>?
DRY. This feels like a helper that would be great to extract as well. Reading the relevant code in trans it seems...similar but difference. I'm not sure whether this IS extractable or not. But it feels like it wants to be extracted :) I guess building up some side-tables might be another way to achieve this.
Nit. Indentation.