From 6701e2bf9663f4de21f7211dbeb3df588eb707c1 Mon Sep 17 00:00:00 2001 From: Jim Blandy Date: Wed, 14 Apr 2021 11:58:52 -0700 Subject: [PATCH] Avoid non-exhaustive matches on Expression. Non-exhaustive matches on `Expression` make it harder to review changes that add new enum variants, because the compiler can't tell you that you've missed a case. Although I believe Clippy is able to do so, I don't think we should make a blanket rule of forbidding wildcard match arms against `Expression`. There are a few matches that are only concerned with a handful of variants, or a single variant. For example, variant, naga::front::spv::Parser::next_block is only concerned with whether an expression is a constant or not. In principle, these sites should also be checked when adding a new variant, but it seems too burdensome to require them to list all the `Expression` variants they don't care about. The principle should be applied only to matches that are already handling most variants. At the moment, there is only one such match on `Expression` in the code base, and it's only missing a few variants, so this is quick to fix. --- src/back/spv/writer.rs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/back/spv/writer.rs b/src/back/spv/writer.rs index 1a6e7a6111..129529f3fc 100644 --- a/src/back/spv/writer.rs +++ b/src/back/spv/writer.rs @@ -1993,8 +1993,10 @@ impl Writer { }); id } - ref other => { - log::error!("unimplemented {:?}", other); + crate::Expression::ImageQuery { .. } | + crate::Expression::Relational { .. } | + crate::Expression::ArrayLength(_) => { + log::error!("unimplemented {:?}", ir_function.expressions[expr_handle]); return Err(Error::FeatureNotImplemented("expression")); } };