Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing field error in initializer for struct with inaccessible fields #87872

Closed
gheoan opened this issue Aug 8, 2021 · 2 comments · Fixed by #87895
Closed

Missing field error in initializer for struct with inaccessible fields #87872

gheoan opened this issue Aug 8, 2021 · 2 comments · Fixed by #87895
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@gheoan
Copy link
Contributor

gheoan commented Aug 8, 2021

Given the following code:

// in file a.rs
#![crate_type = "lib"]

pub struct X {  
  pub f: u32, // remove the field f to get a different error message
  pub(crate) g: u32,
}

// this is to prevent a warning that g is not used
impl X {
  pub fn value(self) -> u32 { self.g }
}
// in file b.rs
#![crate_type = "bin"]

extern crate a;

fn main() {
  let x = a::X {};
  x.value();
}

Using rustc a.rs followed by rustc -L . b.rs, the current output is:

error[E0063]: missing fields `f` and `g` in initializer of `X`
 --> b.rs:6:11
  |
6 |   let x = a::X {};
  |           ^^^^ missing `f` and `g`

Ideally the output should look like:

error: cannot construct `X` with struct literal syntax due to inaccessible fields
 --> b.rs:6:11
  |
6 |   let x = a::X {};
  |           ^^^^

The rationale is the same as for #76077. Following the suggestion provided by the compiler will lead to another error. This can be frustrating with structs that have a large number of fields or fields with complex types, since the effort of adding those fields to the struct literal is in vain.

By removing the field f from the struct, the compiler is reporting that X cannot be constructed, as expected.

Tested on both rustc 1.56.0-nightly (574d37568 2021-08-07) and rustc 1.52.0-nightly (4a8b6f708 2021-03-11).

@gheoan gheoan added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 8, 2021
@TheWastl
Copy link
Contributor

TheWastl commented Aug 9, 2021

I guess this also applies to patterns:

pub mod foo {
    #[derive(Default)]
    pub struct Foo {
        pub x: i32,
        y: i32,
    }
}

fn main() {
    let foo::Foo {} = foo::Foo::default();
}

Playground link

Error:

error[E0027]: pattern does not mention fields `x`, `y`
  --> src/main.rs:10:9
   |
10 |     let foo::Foo {} = foo::Foo::default();
   |         ^^^^^^^^^^^ missing fields `x`, `y`
   |
help: include the missing fields in the pattern
   |
10 |     let foo::Foo { x, y } = foo::Foo::default();
   |                  ^^^^^^^^
help: if you don't care about these missing fields, you can explicitly ignore them
   |
10 |     let foo::Foo { .. } = foo::Foo::default();
   |                  ^^^^^^

For more information about this error, try `rustc --explain E0027`.

Possibly change to something along these lines:

error[E0027]: pattern does not mention field `x` and inaccessible fields
  --> src/main.rs:10:9
   |
10 |     let foo::Foo {} = foo::Foo::default();
   |         ^^^^^^^^^^^ missing field `x` and inaccessible fields
   |
help: include the missing fields and ignore the inaccessible fields in the pattern
   |
10 |     let foo::Foo { x, .. } = foo::Foo::default();
   |                  ^^^^^^^^^
help: if you don't care about these missing fields, you can explicitly ignore them
   |
10 |     let foo::Foo { .. } = foo::Foo::default();
   |                  ^^^^^^

For more information about this error, try `rustc --explain E0027`.

@TheWastl
Copy link
Contributor

TheWastl commented Aug 9, 2021

@rustbot claim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
2 participants