Non-exhaustive enums seem to trouble uniffi

[tmathern]

Repro from branch in contentauth/c2pa-python#82 (clone, checkout the branch, run `cargo build).

In our code,

• impl Signer for RemoteSigner has a function, alg, that returns a SigningAlg enum.
• The enum is defined in a dependency, c2pa-rs. In there, SigningAlg is a non exhaustive enum: https://github.com/contentauth/c2pa-rs/blob/main/internal/crypto/src/raw_signature/signing_alg.rs#L31

It seems this troubles uniffi, as the build fails:

   Compiling c2pa-python v0.6.2 (/git/@CAI/c2pa-python)
error[E0004]: non-exhaustive patterns: `_` not covered
   --> /git/@CAI/c2pa-python/target/debug/build/c2pa-python-3be618cc7bdb8e16/out/c2pa.uniffi.rs:115:1
    |
115 | #[::uniffi::udl_derive(Enum)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pattern `_` not covered
    |
note: `SigningAlg` defined here
   --> /.cargo/registry/src/index.crates.io-6f17d22bba15001f/c2pa-crypto-0.3.0/src/raw_signature/signing_alg.rs:32:1
    |
32  | pub enum SigningAlg {
    | ^^^^^^^^^^^^^^^^^^^
    = note: the matched value is of type `SigningAlg`
    = note: `SigningAlg` is marked as non-exhaustive, so a wildcard `_` is necessary to match exhaustively
    = note: this error originates in the attribute macro `::uniffi::udl_derive` (in Nightly builds, run with -Z macro-backtrace for more info)
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
115 | #[::uniffi::udl_derive(Enum)], _ => todo!()
    |                              ++++++++++++++

For more information about this error, try `rustc --explain E0004`.

[badboy]

This is part of the generated code where it fails:

unsafe impl ::uniffi::FfiConverter<crate::UniFfiTag> for SigningAlg {
    // <snip>

    fn write(obj: Self, buf: &mut ::std::vec::Vec<u8>) {
        match obj {
            Self::Es256 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 1);
            }
            Self::Es384 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 2);
            }
            Self::Es512 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 3);
            }
            Self::Ps256 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 4);
            }
            Self::Ps384 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 5);
            }
            Self::Ps512 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 6);
            }
            Self::Ed25519 {} => {
                ::uniffi::deps::bytes::BufMut::put_i32(buf, 7);
            }
        }
    }

I fear there's no real perfect way to handle this.
At the time of code-generation we don't know that the enum is defined non-exhaustive on the Rust side.

We could require additional annotations in the UDL, so we can generate the _ => case (and then potentially just panic).
Or just always add a _ => panic!("oops") case (but for exhaustive enums that's unreachable code and thus should probably get a #[allow(unreachable_patterns)] on there too)

[jplatte]

I've had a use case with a non-exhaustive enum where it was only relevant to be able to send the enum from the foreign languages to Rust, not the other way around. There the non-exhaustive attribute should be no problem at all, but UniFFI currently has both encoding and decoding in the same trait so the macro always tries to implement both. Is this the same case you're hitting?

[mhammond]

Interestingly, we do have basic support for "flat" enums where it's only possible to send the enum from Rust to foreign code, and that characteristic is "inherited" by container objects which include it - eg, see coverall. I'm not sure how relevant it is here but thought it worth sharing.

[tmathern]

I've had a use case with a non-exhaustive enum where it was only relevant to be able to send the enum from the foreign languages to Rust, not the other way around. There the non-exhaustive attribute should be no problem at all, but UniFFI currently has both encoding and decoding in the same trait so the macro always tries to implement both. Is this the same case you're hitting?

We need to send them around, potentially. In this case, we had it non-exhaustive as a design decision, to easily extend the enum and force the "fallback" handling of the default case.

[bendk]

There's a [NonExhaustive] UDL attribute, would that work?

https://mozilla.github.io/uniffi-rs/latest/udl/enumerations.html#remote-non-exhaustive-enums