Repository navigation
The "cannot create non-exhaustive struct using struct expression" warning should silence the "cannot construct Foo with struct literal syntax due to private fields" warning #147513
Description
Code
// src/lib.rs
#[non_exhaustive]
pub struct Foo {
pub my_field: u32,
private_field: i32,
}// src/main.rs
use exhaustive_test::Foo;
fn main() {
let foo = Foo {
my_field: 10,
};
}Current output
error[E0639]: cannot create non-exhaustive struct using struct expression
--> src/main.rs:4:15
|
4 | let foo = Foo {
| _______________^
5 | | my_field: 10,
6 | | };
| |_____^
error: cannot construct `Foo` with struct literal syntax due to private fields
--> src/main.rs:4:15
|
4 | let foo = Foo {
| ^^^
|
= note: ...and other private field `private_field` that was not provided
Desired output
error[E0639]: cannot create non-exhaustive struct using struct expression
--> src/main.rs:4:15
|
4 | let foo = Foo {
| _______________^
5 | | my_field: 10,
6 | | };
| |_____^
Rationale and extra context
There is no reason to provide two errors for the same issue, and the #[non_exhaustive] issue is the one that should be highlighted since it's explicitly chosen by the struct author.
Other cases
If there is no private field, then the correct output is created.
Rust Version
$ rustc +nightly --version --verbose
rustc 1.92.0-nightly (b6f0945e4 2025-10-08)
binary: rustc
commit-hash: b6f0945e4681bc4d2faa7c22c5f61dc36abf7dd2
commit-date: 2025-10-08
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.2
Anything else?
No response
Activity
chenyukang commentedon Oct 9, 2025
I don't think we need to fix this, it's not the same issue.
if you remove the
non_exhaustiveattribute from struct, the first error will disappear, but now we still need to fix the second one, the second one pointing outprivate fieldswhich is meaningful.Darksonn commentedon Oct 9, 2025
@chenyukang What you're saying assumes that removing
#[non_exhaustive]is the correct solution when you get this error, but generally that is not the right solution. In fact, the error only occurs if the struct is from another crate, and you probably can't modify your dependencies.chenyukang commentedon Oct 9, 2025
The main reason to keep them is there are two different issues, two standalone one's from different check.
I think compiler should give as much useful and necessary information for the issues in code, but also need avoid to be too noisy of course.
Darksonn commentedon Oct 10, 2025
So the context where this came up for me is a type like this one:
I'm using the type for IPC by sending the bytes verbatim over the wire. I'm promising that I won't ever change the size of this struct in the future, and that the existing fields will never go away or be moved to a different offset. However, I may add additional fields in the future (using the space currently occupied by
_pad).Here, the
_padfield serves two purposes:MyDataTypecontains no uninit bytes.MyDataTyperetain the bytes stored in the padding.In this case, if the user tries to construct this struct, then I want them to get the
#[non_exhaustive]error message telling them "hey, there might be additional fields in the future", but I don't really want the user to care about the private_padfield.chenyukang commentedon Oct 11, 2025
yeah, this seems a reasonable reason for hiding the later one.
chenyukang commentedon Oct 11, 2025
Fired PR #147585
also remove the similar error:
error[E0063]: missing field `missing_field` in initializer of `Foo`Rollup merge of rust-lang#147585 - chenyukang:yukang-fix-147513-suppr…
Unrolled build for #147585