rust-lang / rust-lang/rust

Incorrect warning about pointer to non_exhaustive ffi struct not being ffi safe

Open
#132,699 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-FFI A-lints C-bug L-false-positive L-improper_ctypes T-compiler T-lang
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

Rust warns that pointers to structs tagged with non_exhaustive aren't FFI safe in downstream crates. We ran into this in the sdl3-sys crate, where I've marked some FFI types, e.g. SDL_Surface, as non_exhaustive because the internal definition of the type used by the SDL library is larger than the public definition, and the non-public part isn't stable. Marking it with non_exhaustive prevents code from manually constructing their own value that would cause immediate UB if passed to SDL. The non_exhaustive structs are only used through pointers.

Reproduction

Crate a, lib.rs:

#[repr(C)]
#[non_exhaustive]
pub struct Struct {
    pub field: u8
}

extern "C" {
    pub fn create_struct() -> *mut Struct;
    pub fn destroy_struct(s: *mut Struct);
}

Crate b, lib.rs:

use a::Struct;

extern "C" {
    pub fn use_struct(s: *mut Struct);
}
I expected to see this happen:

Either neither crate should warn about this, or both should. non_exhaustive is as useful for FFI types as it is for native Rust types, so I'd prefer that neither crate warned.

If the warning is intentional, I'd like a way to disable it on the type itself (assuming it's safe, but I don't see why it wouldn't be)

Instead, this happened:

Crate b warns that Struct isn't FFI safe. There's no warning for crate a.

warning: `extern` block uses type `Struct`, which is not FFI-safe
 --> b/src/lib.rs:4:26
  |
4 |     pub fn use_struct(s: *mut Struct);
  |                          ^^^^^^^^^^^ not FFI-safe
  |
  = note: this struct is non-exhaustive
  = note: `#[warn(improper_ctypes)]` on by default

warning: `b` (lib) generated 1 warning
Meta

rustc --version --verbose:

% rustc --version --verbose
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: aarch64-apple-darwin
release: 1.82.0
LLVM version: 19.1.1

% rustc +nightly --version --verbose
rustc 1.84.0-nightly (798fb83f7 2024-10-16)
binary: rustc
commit-hash: 798fb83f7d24e31b16acca113496f39ff168c143
commit-date: 2024-10-16
host: aarch64-apple-darwin
release: 1.84.0-nightly
LLVM version: 19.1.1

Contributor guide

Open the contributing guide

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.

Research direction

Reproduce the warning using the two lib.rs examples from crates a and b, focusing on the pointer to the non_exhaustive Struct and the improper_ctypes lint. Trace how the compiler evaluates FFI safety across the crate boundary, then add regression coverage showing the intended warning behavior for both declarations.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.