Clean up `control path` compiler warnings

[asg017]

Some compilers complain when not all "control paths" return a value, like:

char *vec_type_name(enum VectorElementType elementType) {
  switch (elementType) {
  case SQLITE_VEC_ELEMENT_TYPE_FLOAT32:
    return "float32";
  case SQLITE_VEC_ELEMENT_TYPE_INT8:
    return "int8";
  case SQLITE_VEC_ELEMENT_TYPE_BIT:
    return "bit";
  }
}

Though my compiler on MacOS doesn't give these warnings, so will need to find a way to reproduce this

[rujialiu]

I'm using Visual Studio 2022 on Windows 10.

Here are all changes I've made to remove all such warnings. I've manually filtered out these changes from a larger patch including my other workarounds before v0.1.1 exists. Hopefully I didn't miss any.

@@ -1275,6 +1275,7 @@ char *vec_type_name(enum VectorElementType elementType) {
   case SQLITE_VEC_ELEMENT_TYPE_BIT:
     return "bit";
   }
+  return 0;
 }

 static void vec_type(sqlite3_context *context, int argc, sqlite3_value **argv) {
@@ -1986,6 +1987,7 @@ size_t vector_byte_size(enum VectorElementType element_type,
   case SQLITE_VEC_ELEMENT_TYPE_BIT:
     return dimensions / CHAR_BIT;
   }
+  return 0;
 }

 size_t vector_column_byte_size(struct VectorColumnDefinition column) {
@@ -3043,6 +3045,7 @@ static int vec_npy_eachColumn(sqlite3_vtab_cursor *cur,
   case VEC_NPY_EACH_INPUT_FILE:
     return vec_npy_eachColumnFile(pCur, context, i);
   }
+  return 0;
 }

@@ -5163,6 +5182,7 @@ static int vec0Rowid(sqlite3_vtab_cursor *cur, sqlite_int64 *pRowid) {
     return SQLITE_ERROR;
   }
   }
+  return 0;
 }

 static int vec0Next(sqlite3_vtab_cursor *cur) {
@@ -5225,6 +5245,7 @@ static int vec0Eof(sqlite3_vtab_cursor *cur) {
     return pCur->point_data->done;
   }
   }
+  return 0;
 }

@@ -6763,7 +6784,7 @@ static int vec_static_blob_entriesRowid(sqlite3_vtab_cursor *cur,
     return SQLITE_OK;
   }
   }
+  return 0;
 }

 static int vec_static_blob_entriesNext(sqlite3_vtab_cursor *cur) {
@@ -6778,6 +6799,7 @@ static int vec_static_blob_entriesNext(sqlite3_vtab_cursor *cur) {
     return SQLITE_OK;
   }
   }
+  return 0;
 }

 static int vec_static_blob_entriesEof(sqlite3_vtab_cursor *cur) {
@@ -6792,6 +6814,7 @@ static int vec_static_blob_entriesEof(sqlite3_vtab_cursor *cur) {
     return pCur->knn_data->current_idx >= pCur->knn_data->k;
   }
   }
+  return 0;
 }

 static int vec_static_blob_entriesColumn(sqlite3_vtab_cursor *cur,
@@ -6829,6 +6852,7 @@ static int vec_static_blob_entriesColumn(sqlite3_vtab_cursor *cur,
     return SQLITE_OK;
   }
   }
+  return 0;
 }

 static sqlite3_module vec_static_blob_entriesModule = {
@@ -6890,9 +6914,6 @@ static sqlite3_module vec_static_blob_entriesModule = {
 #define SQLITE_RESULT_SUBTYPE 0x001000000
 #endif

-#ifdef _WIN32
-__declspec(dllexport)
-#endif
     int sqlite3_vec_init(sqlite3 *db, char **pzErrMsg,
                          const sqlite3_api_routines *pApi) {
   SQLITE_EXTENSION_INIT2(pApi);
@@ -6977,9 +6998,6 @@ __declspec(dllexport)
 }

 #ifndef SQLITE_VEC_OMIT_FS
-#ifdef _WIN32
-__declspec(dllexport)
-#endif
     int sqlite3_vec_fs_read_init(sqlite3 *db, char **pzErrMsg,
                                  const sqlite3_api_routines *pApi) {
   UNUSED_PARAMETER(pzErrMsg);
@@ -6992,9 +7010,6 @@ __declspec(dllexport)
 #endif

-#ifdef _WIN32
-__declspec(dllexport)
-#endif
     int sqlite3_vec_static_blobs_init(sqlite3 *db, char **pzErrMsg,
                                  const sqlite3_api_routines *pApi) {
   UNUSED_PARAMETER(pzErrMsg);

BTW: As you can see above, I also removed dllexport because I wanted to use statically linking. I also had add the following, before including sqlite-vec.h, otherwise compiler will complain about sqlite3_api.

#define SQLITE_OMIT_LOAD_EXTENSION

It would be great if static linking on windows is better supported, for example, via a macro like SQLITE_VEC_STATIC and SQLITE_VEC_API so that we use dllexport only on windows and not static linking.