Standalone code generation depends on extension types and functions

[poliorcetics]

In recent commits (those after windows-bindgen 0.49), the standalone function is now able to handle TypeKind::Class and TypeKind:: Interface whereas it was unimplemented!() before.

I will need those for GuillaumeGomez/sysinfo#950

Not particularly urgent but IIRC releases are done on request for the crates here ?

[kennykerr]

Sure, I can do that - have you tested with the latest version on github to ensure that it meets your needs, and the resulting bindings work as needed?

[poliorcetics]

Trying it out now

[poliorcetics]

What's missing: at least

• BOOL::ok()
• WIN32_ERROR::ok()
• NTSTATUS::ok()

Those methods are not generated by the windows-bindgen lib

Also, in the documentation, the need to have windows_core has a dependency alongside windows-targets is not mentioned

[poliorcetics]

I'm using commit 72e9bf4 to test, if you push changes I can easily update and retest as needed :)

[kennykerr]

Currently those extensions, like the ok methods, are only included in the windows crate on a per-module basis rather than per-type. This is intentional to deal with a few implementation issues and would require some work to refactor to support standalone code generation. I would like to do that eventually, but that probably won't happen in the short term.

[poliorcetics]

It makes bindings impossible to compile for non-sys versions because they're used in the produced bindings

[kennykerr]

A minimal repro would be appreciated to help me understand what you're trying to achieve. The standalone code generation is still pretty experimental compared with the windows and windows-sys crates and may not be appropriate depending on your goals.

[poliorcetics]

I'll push the sysinfo branch

[kennykerr]

Thanks, the minimal repro involves generating bindings for Windows.Win32.Security.Authorization.ConvertSidToStringSidW with windows_bindgen::standalone_win.

[MarijnS95]

As mentioned in #1720 (comment) the standalone bindings should include pretty much everything from the extension file (e.g. https://github.com/microsoft/windows-rs/blob/78a0dbea48f856b03f3e7e650e0e385047d8a10b/crates/tools/riddle/src/rust/extensions/mod/Win32/Foundation/BOOL.rs), including From<> implementations (but I never got to report that as standalone issue per request, sorry!).

Not sure if this is still an issue since riddle, though.

[poliorcetics]

This has been fixed now, I tried it with windows-bindgen 0.51.1 (the codegen docs are way outdated though)

[riverar]

Thanks for following up @poliorcetics

[poliorcetics]

Thanks for fixing it !

[MarijnS95]

Yup, looks to be fixed indeed 👍

[MarijnS95]

Hmm no, this is not true. I'm using the git version at 41ad38d and no From<BOOL> for bool from the extensions is generated: https://github.com/microsoft/windows-rs/blob/master/crates/libs/bindgen/src/rust/extensions/mod/Win32/Foundation/BOOL.rs.

Only this is generated:

https://github.com/MarijnS95/windows-rs/blob/bef7648ca724ea221e852f30f2cd114df6c5b3d5/crates/samples/windows/dxc/src/bindings.rs#L10-L31

There's no BOOL::ok() here. Bindings are generated with:

https://github.com/MarijnS95/windows-rs/blob/bef7648ca724ea221e852f30f2cd114df6c5b3d5/crates/samples/windows/dxc/bindings.txt#L1-L23

[kennykerr]

See #2517 (comment)

Now that windows-core exists, those extensions could conceivably live there.

[MarijnS95]

@kennykerr ah thanks, I've overlooked that.

Now that windows-core exists, those extensions could conceivably live there.

Sure, but only for types that themselves live in windows-core? Is that true for every type that is currently extended?

[kennykerr]

No. There's no easy fix - that's why I'm generally cautious about adding handwritten extensions.