Consider creating bindings with rustified_non_exhaustive_enum

[FreezyLemon]

Consider using rustified_non_exhaustive_enum instead of the currently used https://github.com/zmwangx/rust-ffmpeg-sys/blob/e14770de907e310ccd62c8b0e8855feb85ebb8f1/build.rs#L1170

The Rust docs have a good explanation of what this does, but the most important part is:

// Cannot match on a non-exhaustive enum without including a wildcard arm.
match error {
  Error::Message(ref s) => { },
  Error::Other => { },
  // would compile with: `_ => {},`
}

This would mean all dependent code (including ffmpeg-next) would be required to use a wildcard arm when matching against an enum create from the FFmpeg header files.

Motivation for this: Currently, building ffmpeg-next can fail if you compile and install FFmpeg from git. The upstream header files might be updated with new enum values which will cause issues because ffmpeg-next uses pattern matching on multiple enums, and as soon as ffmpeg-next-sys creates the bindings with new enum values, these match statements will not be exhaustive anymore and fail to compile: https://cdn.discordapp.com/attachments/697086935763779666/1028476266220888144/unknown.png (image shamelessly stolen from a discord server where this issue happened)

This is a big problem especially on Arch-based (and other) distros which make building and installing directly from git repositories simple.

[Sioxas]

I have the same problem, is there any temporary workaround?

[FreezyLemon]

@Sioxas Well, for now you could roll back to a release version of ffmpeg. You could also look at my PRs (linked to this issue, above your comment) and include the changes in your project's Cargo.toml:

[patch.crates-io]
ffmpeg-next = { git = "https://github.com/FreezyLemon/rust-ffmpeg", branch = "non-exhaustive-enum" }
ffmpeg-sys-next = { git = "https://github.com/FreezyLemon/rust-ffmpeg-sys", branch = "non-exhaustive-enum" }