Harden nested type discovery

[kennykerr]

It turns out that ECMA-335 may include a valid TypeNamespace for a nested TypeDef. 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 a TypeDef is nested directly rather than relying on the absence of a TypeNamespace value.

Scanning the NestedClass table 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 by windows-bindgen.

Fixes: #3468

[riverar]

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 nested accessibility attribute?

[kennykerr]

Good question.

Here's the nested Version type I encountered in the metadata referred to in the #3468 issue:

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.

[riverar]

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.
https://github.com/microsoft/win32metadata/blob/main/sources/ClangSharpSourceToWinmd/ClangSharpSourceWinmdGenerator.cs#L840-L843

(Aside: ILSpy appears to mistakenly refer to these as visibility attributes but is otherwise functioning correctly.)

[kennykerr]

Here's a small optimization: 02eb56b

That at least avoids the binary search in most cases.