Rust API

[benjaminwinger]

A few issues are outstanding, but I think it's close enough for review.

Implements a rust API using the cxx crate, which was chosen over bindgen since it makes it possible to translate C++ exceptions into rust errors, and provides a bunch of extra safety checks.

The rust build runs make debug/make release to get the kuzu libraries, and then passes those libraries to cargo to link to the rust library. This process should be transparent to any rust applications using kuzu with the obvious exception that they will need kuzu's build dependencies.

Rust is const by default, which led to me making several functions const which didn't need to not be const.

Outstanding issues:

• Linking to kuzu in build.rs is fragile and platform-specific (since for static libraries it also needs to link the dependencies explicitly):
  • It's working on Linux, but I've tested it on windows and found some problems which I'm still looking into (naming differences, and a different stdlib).
  • For some reason, when linking the rust tests it fails with undefined symbol errors if they aren't also linked to libssl/libcrypto. I've hidden this behaviour behind a KUZU_TESTING environment variable since it doesn't appear to affect rust software building against the kuzu crate.
• There are some test failures I ran into which may indicate underlying problems with kuzu:
  • Fetching Null values from the database is causing a buffer manager failure (kuzu/src/include/storage/buffer_manager/bm_file_handle.h:173: kuzu::storage::PageState* kuzu::storage::BMFileHandle::getPageState(kuzu::common::page_idx_t): Assertion `pageIdx < numPages && pageStates[pageIdx]' failed). This might be related to WITH NULL segmentation fault #1643.
  • Passing VarLists as parameters for node creation and querying the result gives back an empty list (presumably unsupported? Add List-type literal and parameter #557 (comment), but unlike other unsupported types it's not giving an error, which is at least inconsistent behaviour).
• I haven't set anything up for deployment to crates.io (the process is relatively straightforward, and could probably be done from CI).
• QueryResult behaves a little unusually since it embeds the iterator in itself, which leads to things like rust's Display trait not being able to be used since toString mutates the QueryResult (instead I added a display(&mut self) method). I feel like it would make more sense for the QueryResult to have a const function which produces an iterator, but I'm not sure how easy of a change that would be.
• Currently this can only be built against kuzu when it's compiled with the bundled source code. Having the crate link against the release binaries by using environment variables to specify where they are would be possible except that the headers are different, so the kuzu_rs.h shim would need to import kuzu.h instead of main/kuzu.h, etc. (could probably be handled with some macros).
• A few types are not implemented (RECURSIVE_REL, SERIAL, ARROW_COLUMN, MAP, UNION).

[acquamarin]

I think our naming convension is not to add a '-' between the language name and test. (e.g. nodesjstest rather than nodejs-test)
So rename to rusttest

[benjaminwinger]

Done

[acquamarin]

As we discussed, we currently don't support giving null/list values to parameters of preparedStatement.
you can remove this.

[benjaminwinger]

Done

[acquamarin]

let's test rust on clang and windows as well.

[benjaminwinger]

I added a rustfmt check. Is it fine to have it separate like the clang-formatting-check, or now that there's multiple (maybe more in future: #1464) should the formatting checks be grouped together as multiple steps in a single job?

[mewim]

It is fine to have separate format checks. Since checking format is a very simple job, maybe we should consider running it on GitHub runner instead of self-hosted moving forward?