Skip to content
This repository was archived by the owner on Nov 26, 2020. It is now read-only.

GUADEC 2015 BoF

Jump to bottom
Mikhail Zabaluev edited this page Oct 20, 2015 · 10 revisions

Somewhat incomplete notes taken at or around the Rust BoF at GUADEC 2015.

Projects

There are two known projects aiming to create Rust bindings for GNOME software stacks. The projects differ in scope, approach, activity, and "human connections".

  • GI-Rust. Started at about Rust 0.6. Aims to provide mostly automated generation of Rust bindings from GIR XML. The proof-of-concept mock bindings are kept up to date with Rust development; the generator is still vaporware. Developed by Mikhail Zabaluev as a free-time personal project, though there have been some contributions from other developers.

  • Gtk-rs. Developed by a team, has seen more activity lately, but no participation in the wider GNOME community (at the time of the BoF, contact through Mikhail on Gitter IM). The high-level bindings are written manually, however there's been effort in automating creation of -sys crates.

Scope

The initial intent for GI-Rust is to develop purely client-side bindings, and possibly add subclassing in Rust later. Apparently people want more (e.g. writing custom Gtk widgets in Rust), but the complexity is daunting.

Generating GObjects using Rust: may be doable with trampolines initialized at GType initialization.

Enabling plugins (for IDEs etc.) written in Rust: provide dynamic GType registration for modules.

Low-hanging fruit: generator for -sys crates

By convention on crates.io, the -sys crates import C APIs without providing any Rust idioms. This is a much smaller target for an automated generator, as the C declarations are fairly well represented in GIR.

The Gtk-rs project has a generator. There are some questionable choices in implementation, but on the whole it seems to be workable.

Tools support

It should not be hard to add a language spec XML file for gtksourceview.

Rust Racer: autocompletion

Support for integrated source browsing in Builder is complicated by lack of incremental compilation. Updated: There is an RFC in progress.

Build systems

Cargo is native to Rust and should be supported as first-class citizen.

Automake support is possible, but not seen as priority. Incorporation into bigger autotools/make projects can be done as a subdir project built with Cargo and a shim makefile to invoke cargo for standard GNU targets.

Issues

Missing features in GObject-introspection

  • No thread safety annotations. Bug 742509. The conservative assumptions of thread-unsafe objects result in Rust bindings unable to send or share objects between threads. GMainContext, attached GSources got hand-written bindings, but for broader support an annotation would be a better solution.

  • Annotation (out)(transfer none) gives no guarantees on the lifetime of the 'borrowed' value (basically you shouldn't do anything potentially mutative anywhere while using it). This defeats one of the most useful features in Rust. Bug 737962.

  • No bytestring type. Bug 737883. Agreement: not needed, as zero-terminated byte strings are representable, and we don't need any other special treatment for string data.

  • Special-case destruction methods, e.g. gst_buffer_unmap.

  • Copy-on-write: the dynamic writability semantics of e.g. gst_mini_object_make_writable. Make-unique-reference methods per se are doable as long as the self parameter and the return value are annotated (transfer full).

  • FnMut closures are problematic with recursive callbacks. FFI calls made inside the closure call may cause the callback to recurse, modifying the closure environment. This is opaque for the optimizer. Experimentation needed to see if there is a real issue.

Defaults cannot be taken at face value

  • The default string type is 'utf8'; in reality many APIs produce non-UTF8 strings in return values and output parameters. Safe Rust bindings have to return a bytestring for the consumer to perform a checking conversion, which is wasteful in the majority of correctly annotated cases.

  • Functions returning pointers not annotated (nullable) may still return null. Arguably should be treated as an annotation bug resulting in panic (runtime checks in debug builds).

Ergonomics

  • Functions returning false when setting GError could be bound to return Result::Ok(()) instead of a redundant bool success value. Bug 708301. For functions with no out parameters, this is only a nuisance issue; output parameters, however, need to be bound into the return tuple together with the return value, which only adds noise in most cases.

Clone this wiki locally