Allow libloading v0.7 and v0.8

[daxpedda]

The only relevant change in v0.8 is the migration to windows-sys: https://docs.rs/libloading/0.8.0/libloading/changelog/r0_8_0/index.html.

This is done in the same spirit as gfx-rs/wgpu#3711 because I heard Mozilla, who is using wgpu, isn't ready to migrate to windows-sys yet, see gfx-rs/wgpu#3207.

d3d12 did this as well: gfx-rs/d3d12-rs#43.

Originally coming from here: #67 (comment).

[Elabajaba]

I'm not sure if this is necessary for wgpu, since hassle-rs is behind an optional feature that afaik mozilla doesn't enable.

[cwfitzgerald]

Either way, hassle-rs brings windows into the dep tree, so until moz figures out windows-rs, we can't use fully depend on hassle-rs. I would vote this as unnecessary.

[daxpedda]

Alright, thanks!

[MarijnS95]

Either way, hassle-rs brings windows into the dep tree

@cwfitzgerald where does it bring this in (prior to #67) exactly? Searching for windows in Cargo.lock only shows the winapi crates.

[cwfitzgerald]

You know what, I just totally confused hassle-rs for gpu-allocator 🤦🏻‍♂️

Let's re-open and merge this.

[MarijnS95]

Approving, though I hope we're migrating away from winapi now 😉

[cwfitzgerald]

Updated situation from mozilla land is that windows-sys 0.48.0 is allowed, but windows isn't.

[MarijnS95]

@cwfitzgerald if we were to use windows directly in this crate it'd have to be the main/core crate for COM interoperability. But libloading is supposedly only using windows-sys so it wouldn't have made a difference to land this in the end?

[cwfitzgerald]

Yeah now that I'm putting it all together, this doesn't matter:

• libloading is only using windows-sys, which is allowed anyway.
• Mozilla is never going to use DXC, and hassle-rs never shows up in mozilla's dep tree due to it being behind a feature flag in wgpu.

I think I got hassle-rs and gpu-allocator confused again