[Feature request] non_exhaustive structs

Open
#3,495 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, rust
Domain
devtools

Research direction

The issue names no files or tests. Start by locating bindgen's struct-generation and configuration paths, then inspect how repr(C), Default, and other generated attributes are handled. Done means an optional setting can apply non_exhaustive to all or selected structs, with the layout and C-compatibility trade-offs covered by tests.

Written by the indexing model from the issue text.

Description

From a C API point of view, adding a field to a struct is often not seen as a breaking change, for fields that are not mentioned when giving a struct by value are zeroed. The Rust equivalent would be to make all structs non_exhaustive (which, unless the type is not supposed to be constructed from Rust, only makes sense if Default is derived on it).

Therefore, I think it would make sense to enable having non_exhaustive on structs, so that more C non-breaking changes can be translated to Rust non-breaking changes. A -sys crate using this would merely need to make the decision of whether either

  1. the underlying C library only adds fields at the end (or in alignment-guaranteed gaps), or
  2. the -sys crate makes the concession that the #[repr(C)] merely guarantees that it is aligned with the linked C code, but no concrete layout guarantee.

Is this something that you agree would make sense to have in bindgen (say, as an optional "make all (or selected) structs non_exhaustive")? Is there anything that a PR implementing this could do to make 2. go over better? (I don't think we can make the repr property non-pub, but maybe there are tricks I'm missing.)

Dominant language
Rust
Stars
5.3k
Forks
846
Avg merge
2d 6h
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-lang/rust-bindgen

All issues in rust-lang/rust-bindgen

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.