Harden nested type discovery #3471
Conversation
|
I couldn't find it explicitly codified either, but the spec does state that nested type names are scoped by their enclosing type. So I don't think the namespace field serves any meaningful purpose at that point. Can we instead peek at the ClassType and check for the |
|
Good question. Here's the nested 
Unfortunately, it does not have any of the nested bits set. This is what it should look like: 
So it may still be that this is bad metadata. I'm not too sure, but that doesn't work reliably. |
|
Interesting. I agree, looks like bad metadata. Would file a bug on win32metadata; it seems only nested structs are emitted with the appropriate nested attributes. (Aside: ILSpy appears to mistakenly refer to these as visibility attributes but is otherwise functioning correctly.) |
|
Here's a small optimization: 02eb56b That at least avoids the binary search in most cases. |
2 participants
It turns out that ECMA-335 may include a valid
TypeNamespacefor a nestedTypeDef. I have never encountered this until #3468 but I can't find anything in the spec to indicate that this is invalid. So I've hardened the reader to check whether aTypeDefis nested directly rather than relying on the absence of aTypeNamespacevalue.Scanning the
NestedClasstable is slightly slower, but fortunately it is not much slower as this table is sorted and a binary search can be used. I may revisit this further and attempt to index the types in a single pass instead, but for now this solves the issue encountered by #3468 as I can now also reliably exclude nested types that are not structs. Only nested structs are supported bywindows-bindgen.Fixes: #3468