Port Module Skill

Guide for porting a C module to Rust.

Arguments

The module name to port should be provided as an argument (e.g.,

/port-module triemap

).

Module to port:

$ARGUMENTS

Usage

Use this skill when starting to port a C module to Rust.

Instructions

1. Analyze the C Code

First, understand the C module you're porting (look for

$ARGUMENTS.c

and

$ARGUMENTS.h

in

src/

):

• Read the

  .c

  and

  .h

  files in

  src/

• Identify what is exposed by the header file:
  • Does the rest of the codebase have access to the inner fields of the data structures defined in this module?
  • Are types always passed by value or by reference? A mix?
  • Can the corresponding Rust types be passed over the FFI boundary?
• Understand data structures and their lifetimes
• Identify which types and functions this module imports from other modules:
  • Determine if those types are implemented in Rust or C
  • If those types are implemented in Rust, identify the relevant Rust crate
  • If those types are implemented in C, understand if it makes sense to port them first to Rust or if it's preferable to invoke the C implementation from Rust via FFI
• Note any global state or Redis module interactions
• Identify which tests under

  tests/

  are relevant to this module

2. Define A Porting Plan

Create a

$ARGUMENTS_plan.md

file to outline the steps and decisions for porting the module. Determine if the C code should be modified, at this stage, to ease the porting process. For example:

• Introduce getters and setters to avoid exposing inner fields of data structures defined in this module.
• Split the module into smaller, more manageable parts.

3. Create the Rust Crate

cd src/redisearch_rs
cargo new $ARGUMENTS --lib

4. Implement Pure Rust Logic

• Create idiomatic Rust code
• Add comprehensive tests
  • Ensure that all C/C++ tests have equivalent Rust tests
• Document public APIs with doc comments
• For performance sensitive code, create microbenchmarks using

  criterion

• Use

  proptest

  for property-based testing where appropriate
• Testing code should be written with the same care reserved to production code

5. Compare Rust API with C API

• Review the public API of the new Rust module against the C API in the header file
• Ensure that differences can be bridged by adding appropriate wrappers or adapters
• Go back to step 1 if discovered differences cannot be bridged without a re-design

6. Create FFI Wrapper

Create an FFI crate to expose the new Rust module to the C codebase:

cd src/redisearch_rs/c_entrypoint
cargo new ${ARGUMENTS}_ffi --lib

FFI crate should:

• Expose

  #[unsafe(no_mangle)] pub extern "C" fn

  functions
• Handle null pointers and error cases
• Convert between C and Rust types safely
• Document all unsafe blocks with

  // SAFETY:

  comments

7. Wire Up C Code

• Delete the C header file and its implementation
• Update the rest of the C codebase to import the new Rust header wherever the old C header was used

C header files for Rust FFI crates are auto-generated. No need to use their full path in imports, use just their name (e.g.

#include $ARGUMENTS.h;

for

${ARGUMENTS}_ffi

)

8. Test The Integration

./build.sh RUN_UNIT_TESTS               # C/C++ unit tests
./build.sh RUN_PYTEST                   # Integration tests

Example: Well-Ported Module

See

src/redisearch_rs/trie_rs/

for a high-quality example:

• Pure Rust implementation with comprehensive docs
• Extensive test coverage
• Clean FFI boundary in

  c_entrypoint/trie_ffi/