use windows crate directly

[astraw]

This drops a lot of unsafe code on Windows. For now, this pulls in the windows crate using git. When this is released it we can update this PR.

See microsoft/windows-rs#2317 and microsoft/windows-rs#2318

Thanks to @Kijewski @kennykerr and @riverar

[riverar]

Sweet! ✌️

[astraw]

(The failing tests are unrelated noise - they were already failing on a scheduled rebuild of the main branch. I guess it has something to do with the recently released rust 1.67, cross compilation, and freebsd not playing nicely together.)

[Kijewski]

Windows-rs 0.46 was released, and should be usable for us now. 🎉

[lopopolo]

Looks good and I love dropping all of this unsafe. Thanks all!

[kennykerr]

[astraw]

Thanks everyone, especially @kennykerr.

[MarijnS95]

Looks like windows 0.47 already dropped: can we get a bump and release to that?

@Jake-Shadle this is also a prime candidate for windows-bindgen except for the use of COM objects, for which we're waiting on @kennykerr to separate manual code out into windows-core first; and then hope that crate releases less often if breaking changes are only in the metadata and generated output.

[astraw]

Looks like windows 0.47 already dropped: can we get a bump and release to that?

Done in v0.1.55

[MarijnS95]

That's fast, thanks!

[MarijnS95]

Looks like windows 0.47 already dropped: can we get a bump and release to that?

@Jake-Shadle this is also a prime candidate for windows-bindgen except for the use of COM objects, for which we're waiting on @kennykerr to separate manual code out into windows-core first; and then hope that crate releases less often if breaking changes are only in the metadata and generated output.

I recently tried this now that windows-bindgen is capable of generating "minimal" bindings that leverage windows-core 0.51 rather than the full windows crate.

Unfortunately/obviously this doesn't suffice the MSRV 1.48 policy of this crate thanks to edition = "2021" rust-version = "1.56" in the windows-core crate.

Diff is here: https://github.com/MarijnS95/iana-time-zone/compare/windows-core

I generated the bindings without --config package because this crate really shouldn't have Windows features leaking into its [features] array (beyond those being appended at the end of Cargo.toml). Unfortunately this means the whole Windows.Globalization.Calendar type is generated including function signatures that depend on other types/modules, without cfg guards. All these extra types (and all their dependencies, etc) have to be included to make the Windows module compile; while users may end up not having to download the windows crate as a result, they may end up compiling more code that way.

Still appears to be a half-second (approx!) win though, running:

cargo clean && cargo b --timing

Before:

After:

CC @kennykerr, you might be interested in this. Note also that the compiler suggested that Windows.Foundation.DateTime and Windows.Foundation.TimeSpan could have been imported from windows_core::imp::*, should/could bindgen take care of that?