Mark MappingTarget as #[non_exhaustive] for increased semver flexibility

[Enselic]

This will allow us to add new enum variants in the future without breaking
semver compatibility. See
https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute

Since we already added an enum variant since v0.18.3, now is a good time to mark
it as #[non_exhaustive]. Even if we currently always bump major version (since we are on 0.x.x) there will come a time when we don't, and then it's nice to have this prepared.

[sharkdp]

Nice. If I understand correctly, we still get exhaustiveness-checking within this crate ("Within the defining crate, non_exhaustive has no effect."). And the change to src/bin/bat/main.rs is purely cosmetical?

Or do we only keep exhaustiveness-checking within bat-the-library?

[Enselic]

It is correct that within the lib, we don't need any wildcard. This code compiles when added to the lib:

fn in_lib() {
    let e = MappingTarget::MapToUnknown;
    match e {
        MappingTarget::MapTo(_) => todo!(),
        MappingTarget::MapToUnknown => todo!(),
        MappingTarget::MapExtensionToUnknown => todo!(),
    }
}

The change in src/bin/bat/main.rs was not primarily cosmetical, but required to fix the build. Since the binary is its own crate, non_exhaustive takes effect. The same code as above in the lib fails to compile in the bin:

fn in_bin() {
    let e = MappingTarget::MapToUnknown;
    match e {
        MappingTarget::MapTo(_) => todo!(),
        MappingTarget::MapToUnknown => todo!(),
        MappingTarget::MapExtensionToUnknown => todo!(),
    }
}

error[E0004]: non-exhaustive patterns: `_` not covered
  --> src/bin/bat/main.rs:39:11
   |
39 |     match e {
   |           ^ pattern `_` not covered
   |

[sharkdp]

Since the binary is its own crate

Ok, I wasn't sure about the precise boundaries/terminology here. I thought we have a "lib" part of the bat crate and a "bin" part of the bat crate.

Thank you for the explanation!