Fix generating bindings for dead code#8065
Conversation
This commit fixes a bindgen problem where dead types, which had no generated bindings, could be referred to from other dead types, which did have generated bindings. The fix is to not generate code for dead types at all by fixing how type information is analyzed.
| a(live-type), | ||
| b(dead-type), | ||
| } | ||
| } |
There was a problem hiding this comment.
Not clear to me how this tests liveness since both interfaces are part of the imports?
There was a problem hiding this comment.
Ah good point, I should clarify, liveness is calculated in terms of what's used by imported/exported functions. No function actually uses dead-type or v but live-type is used by a function, and so we don't generate bindings for dead-type and this PR fixes a bug where we previously tried to generate bindings for v despite nothing using it.
alexcrichton
requested review from
dicej and
elliottt
and removed request for
dicej and
fitzgen
| for (t, _) in resolve.types.iter() { | ||
| self.type_id_info(resolve, t); | ||
| } |
There was a problem hiding this comment.
Does doing this step first mean that the calls to self.type_info in type_info_func should never traverse the whole type (due to the early exit if the entry exists already)?
There was a problem hiding this comment.
Not for this, but the below bits would still need it for setting the owned/borrowed bits.
It's probably best to switching this to LiveSet one day as a future refactoring
3 participants
This commit fixes a bindgen problem where dead types, which had no generated bindings, could be referred to from other dead types, which did have generated bindings. The fix is to not generate code for dead types at all by fixing how type information is analyzed.
Closes #8057