Add windows-bindgen warning for methods elided by missing types

[riverar]

Suggestion

windows-bindgen currently elides methods without warning when parameter/return types are missing (e.g., as a result of improper bindgen filter configuration). This can lead to unexpected gaps in generated output and make it more difficult for me to find my silly mistakes.

[kennykerr]

I had a quick look at this - its a challenging feature request.

• Restructuring windows-bindgen to have an analysis phase where this can be collected before code generation proper begins so that warnings/errors can be batched up. Otherwise it would be rather inconvenient to have to run bindgen repeatedly to weed out all the missing types.

• Rolling up types to the most immediate culprit would require further restructuring as today bindgen just builds a container of required types and walks the container to ensure that all types are included. So for example if you want to generate IEnumVARIANT the Next method just requires VARIANT but that type requires all kinds of other types. Tracking them all down and then ordering them in such a way that as to produce the most concise list is challenging.

• Deciding at what point you no longer want to include omitted methods is also not obvious. Take that example further and you'll realize that while you may want the Next method and its VARIANT, do you really want every method of every interface that VARIANT touches? And if not then how/when do you or bindgen decide to stop.

For reference, here's what you'd need to include in the filter to include the Next method.

--filter
    BINDPTR
    DESCKIND
    DISPATCH_FLAGS
    DISPPARAMS
    EXCEPINFO
    FUNCDESC
    FUNCKIND
    IDLDESC
    IEnumVARIANT
    IMPLTYPEFLAGS 
    IRecordInfo
    ITypeComp
    ITypeInfo
    ITypeLib 
    SAFEARRAY
    TLIBATTR 
    TYPEATTR
    TYPEDESC
    TYPEKIND
    VARDESC
    VARENUM
    VARIANT
    VARIANT_BOOL

Some of these would be implied but my simple test for trying to sniff them out came up with this more exhaustive list. Pruning it down to avoid implied dependencies would be harder...

[kennykerr]

Of course if ever there was a pathological case then VARIANT would be it. 😆 This is not representative so I don't think its worth "solving" for such a scenario.