fix: handle missing expression type in protobuf import correctly (#71)

This PR fixes the handling of `Expression` protobuf messages that do not
of the `expression` type set. Such a message would be invalid Substrait
but valid protobuf, so the import logic has to be able to handle that
case gracefully. The PR now has a dedicated `case` for that case.

Signed-off-by: Ingo Müller <[email protected]>

Author: ingomueller-net

lib/Target/SubstraitPB/Import.cpp

@@ -213,10 +213,12 @@ importExpression(ImplicitLocOpBuilder builder, const Expression &message) {
     return importFieldReference(builder, message.selection());
   case Expression::kScalarFunction:
     return importScalarFunction(builder, message.scalar_function());
+  case Expression::REX_TYPE_NOT_SET:
+    return emitError(loc) << Twine("expression type not set");
   default: {
     const pb::FieldDescriptor *desc =
         Expression::GetDescriptor()->FindFieldByNumber(rex_type);
-    return emitError(loc) << Twine("unsupported Expression type: ") +
+    return emitError(loc) << Twine("unsupported expression type: ") +
                                  desc->name();
   }
   }