GSoC Rust UNO API Weekly Update 2

[Mohmed Ali]

Hi all,

I’ll outline the progress from Week 2 of the Rust–UNO binding project.
Quick Summary

Week 2 focused on building the core FFI infrastructure to safely bridge
Rust and LibreOffice's C API. This work is documented as patch #186425
<https://gerrit.libreoffice.org/c/core/+/186425> in the LibreOffice Gerrit
repository. The headline achievement is a complete infrastructure that
handles everything from build system integration to automatic memory
management, with the first high-level API (string handling) working
end-to-end.
What Was Built This WeekProject Structure

The project now has a well-organized codebase:

rust_uno/
├── src/
│   ├── lib.rs          # Main library with public API
│   ├── types.rs        # SAL type definitions and conversions
│   ├── string.rs       # OUString safe wrapper + unsafe FFI functions
│   └── bindings.rs     # Generated FFI bindings (temporary, gitignored)
├── cpp/
│   └── embindtest.cxx  # Custom C++ test component
├── tests/
│   └── integration_tests.rs # Comprehensive test suite
├── examples/
│   ├── basic_usage.rs  # Practical usage examples
│   └── string_examples.rs # UNO string handling examples
├── build.rs           # Build system integration
└── Cargo.toml         # Project configuration

Key Achievements

This week delivered several major accomplishments that established a solid
foundation for the project. The implementation now includes *foundational
FFI infrastructure* that allows users to work with LibreOffice strings
using natural Rust code while all the complexity is handled behind the
scenes. The *memory safety* integration is particularly noteworthy -
LibreOffice's reference counting was successfully bridged with Rust's
ownership system, achieving zero memory leaks.

*Performance* metrics are excellent with fast clean builds, incremental
builds, and test execution times. The *test-driven development* approach
proved invaluable, as writing tests first caught several UTF-8 conversion
and memory management bugs that would have been much more difficult to
debug later in the development cycle.

*Practical examples* were also created to demonstrate the API usage,
showing how developers can work with UNO strings using natural Rust
patterns while the FFI complexity remains completely hidden.
Technical Deep Dive

One significant challenge was LibreOffice's build system complexity. The
initial naive approach failed with hundreds of compilation errors. This
revealed that LibreOffice's exact build configuration needed to be mirrored
rather than simplified. The solution automatically detects the LibreOffice
installation and replicates all compiler flags, include paths, and
preprocessor definitions.

For memory management, the discovery was that LibreOffice's reference
counting maps beautifully to Rust's RAII patterns. By implementing Drop for
automatic cleanup and Clone for reference counting, seamless integration
was achieved where LibreOffice objects are automatically managed by Rust's
ownership system.
What This Enables

With this foundation in place, the following capabilities are now available:

   - Create UNO strings naturally with automatic memory management
   - Build more complex types using the same layered approach
   - Move on to implementing UNO services and interfaces
   - Provide a completely safe API while maintaining full LibreOffice
   compatibility

Next Steps

With the foundational infrastructure now complete, development will
continue to support the additional types needed for full UNO integration.
This includes extending the type system and building upon the established
architecture to provide comprehensive LibreOffice API access through Rust.

Best regards,
Mohamed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20250622/4e7d6a1a/attachment.htm>