Update derive_more dependency about rspirv

[MarijnS95]

Hi @XAMPPRocky, I've previously explored this path and the problem is that newer derive_more does not omit duplicate impl From<>, instead requiring us to manually add #[from(ignore)].

Either:

• We take this issue to derive_more and ask to reintroduce this behaviour;
• Add some extra logic in the autogenerator to emit #[from(ignore)] on all types that occur more than once.

[XAMPPRocky]

We take this issue to derive_more and ask to reintroduce this behaviour

Well I'm not the maintainer, but I think a reasonable proposal could be adding a container level parameter for the from_derive that provides this behaviour.

#[derive(From)]
#[from(ignore_conflicting_types)]
pub enum Foo {
    Foo(u32),
    Bar(u32),
}

Add some extra logic in the autogenerator to emit #[from(ignore)] on all types that occur more than once.

I'd maybe go step further at that point and auto-generate the From impl in the crate and remove derive_more as a dependency entirely.

Another option might be to move the derive_more crate into the autogen crate, and call the derive_more::derive_from at codegen time, so that the generated code only contains the From impls and doesn't require derive_more as a dependency.

[MarijnS95]

@XAMPPRocky I really like the idea of calling derive_more::from_derive at regen/autogen time to get rid of the "runtime" dependency completely. The signature takes and generates a TokenStream making it really easy to plug into the current solution. However, derive_more is a proc-macro = true crate, imposing all kinds of nasty restrictions on exports.

Working around that results in:

thread 'main' panicked at 'procedural macro API is used outside of a procedural macro', library/proc_macro/src/bridge/client.rs:331:17

😞

Fixing the duplication in rspirv is a bit of a mess too as there's no comparison or hashing on TokenStreams. I can probably work the duplication check elsewhere in the code but stringifying is easiest: master...MarijnS95:derive-more

Note that I've only fixed Operand whose ::from is actively used. We should probably apply the same treatment to Decoration if used externally.

I'm more inclined to fix this upstream, given that code for that was already available upstream at some point.