Windows-rs: Enable build.rs support

[Serentty]

Using both IntelliJ Rust and Visual Studio Code with RLS, the windows module produced by the import!() macro is not visible at all to code completion. I understand that it's difficult to deal with code completion when the bindings are generated at build-time, but this makes it harder to explore and learn the WinRT APIs.

[kennykerr]

Yes, this is something that I'd really like to see working soon.

[Alovchin91]

Let me add my 2 cents to this conversation: I believe rust-analyzer is the way forward for a language server for Rust (see RFC 2912), so it probably makes sense to focus on supporting it rather than RLS (maybe by contributing to the rust-analyzer itself).

[kennykerr]

Yes, I've been using rust-analyzer lately. I mention it here:

https://github.com/microsoft/winrt-rs/wiki/Contributing

I does seem to work a lot better. I suspect it will work out-the-box if you stick the winrt::import in a separate crate, but I'm not too sure. We haven't started looking into IDE usability yet.

[matklad]

Hey, author of rust-analyzer here. We do have preliminary support for proc-macros (cc @edwin0cheng, who implemented this), but we don't currently support function-like macros.

When we do implement support for it, code completion should probably work fine.

However, even with perfect code-completion, I doubt that we'll be able to do proper goto definition with the current setup. And goto def to the guts of the generated API seems an important use-case for discoverability. In theory, we can make goto def work by synthesizing expanded file on the fly, but that won't be very useful, as, unformatted generated files are not really readable.

Additionally, long term we do want to WASM-sandbox macros in IDE, which might make reading interface files impossible.

So, for the above two reasons, I would probably advice to consider a boring build.rs code generation as an alternative. Not that we support build.rs significantly better, but, long-term, it seems like a better option for IDE support. In rust-analyzer itself, we use source code generation for our syntax trees, and not a proc macro, for roughly the same reasons.

[kennykerr]

Thanks for feedback, Aleksey. I do plan to provide an option to generate the code from within build.rs as as alternative. It's certainly a ton easier when you can step through the code while debugging. 😊

And if it will help with the IDE that makes it even more compelling. I think the primary use case for the import macro is for simpler single-file programs or samples where you might not want the complexity of a build.rs file. Either way, the code generation is already factored out into a separate crate (from the macro) so this should not be hard to do.

[rylev]

Initial support was added in #154. Let us know if you run into any issues.

[Serentty]

Ooh, it's great to see everything moving so quickly.