Feature request: use DST to represent structures with flexible array members about rust-bindgen

[emilio]

Yeah to be clear I meant to make __IncompleteArrayField optionally a DST, with the same-ish API to consumers, and we'd keep the current version as default at least for a bit. But yeah I guess you'd need from_ptr and such for the new version anyways so maybe it's not such a great idea.

[jsgf]

Prototype implementation in #2772

[emilio]

Hmm, this seems fine, but maybe we should just make the implementation of __IncompleteArrayField use them or so? Would that not be feasible?

[jsgf]

That's a possibility but there's a few downsides:

• It currently relies on nightly features, and I don't know what their stabilization path is
• It's a pretty large back-compat break

Specifically for the second, since these become DST types, it means it's no longer possible to directly reference them by value, so you wouldn't be able to do something like:

let hdr = msg { ... set up fields ...};
// (something to set up payload)
*ptr = hdr;

That's not the end of the world of course - that's why from_ptr_mut exists.

The other problem is that all pointers and references to these objects will be fat, and so not C-ABI compatible. So something like:

struct controlblock {
    struct msg *messagequeue;
};

could not be directly converted to:

#[repr(C)]
struct controlblock {
    messagequeue: *mut msg,
}

Currently this proposed API is using *mut/const () as the thin placeholder, but we could define associated types for typed thin variants, eg:

#[repr(C)]
struct controlblock {
    messagequeue: *mut msg::Thin,
}

Likewise you wouldn't be able to directly pass or return the fat pointers to/from C-ABI functions.

I don't think any of these are show-stoppers; structures with flex array have always been a bit awkward to deal with, and I think this API is an accurate reflection of that (ie, it would make it harder to get things wrong). If we could wave a magic wand to stabilize the features and update all existing code to the new API, then I think we could replace __IncompleteArrayField entirely.

[jsgf]

BTW I also experimented with this idea using a trait (https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=114e0ca2cbc10523037946a7d9c61a06) , since it's a fairly self-contained abstraction that you might want to generalize over.

But as far as I know bindgen doesn't have a support library crate where this could live, and it doesn't seem like it makes sense to emit a separate variant of this trait for each bindgenned module - that would be no better than the current proposal just using intrinsic methods.

[jsgf]

I've published PR #2772 with a fairly complete implementation of this idea.

[jsgf]

I think #2772 is ready for review.