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

E0063 should not suggest adding inaccessible private fields #76077

Closed
kornelski opened this issue Aug 29, 2020 · 1 comment · Fixed by #76524
Closed

E0063 should not suggest adding inaccessible private fields #76077

kornelski opened this issue Aug 29, 2020 · 1 comment · Fixed by #76524
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kornelski
Copy link
Contributor

kornelski commented Aug 29, 2020

This error message could be more helpful:

pub mod foo {
    pub struct Foo {
        you_cant_use_this_field: bool,
    }
}

fn main() {
    foo::Foo {};
}

error[E0063]: missing field you_cant_use_this_field in initializer of foo::Foo

It complains about lack of a private field in the initializer, but this problem can't be solved by adding the field. The implied solution is impossible, and will only lead to another dead-end error.

It would be better to explain in general that this struct can't be constructed from a literal syntax here, because it contains private fields. Bonus points for finding methods that return Self and suggesting them.

related forum thread

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 29, 2020
@estebank estebank added the D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. label Aug 29, 2020
@bors bors closed this as completed in 9f8a782 Sep 10, 2020
zackmdavis added a commit to zackmdavis/rust that referenced this issue Jan 17, 2021
In rust-lang#76612, suggestions were added for missing fields in
patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the
last field. This resulted in the "if you don't care about missing
fields" suggestion to recommend code with a trailing comma after the
field ellipsis (`..,`), which is actually not legal ("`..` must be at
the end and cannot have a trailing comma")!

Incidentally, the doc-comment on `error_unmentioned_fields` was using
`you_cant_use_this_field` as an example field name (presumably
copy-paste inherited from the description of Issue rust-lang#76077), but
the present author found this confusing, because unmentioned fields
aren't necessarily unusable.

The suggested code in the diff this commit introduces to
`destructuring-assignment/struct_destructure_fail.stderr` doesn't
work, but it didn't work beforehand, either (because of the "found
reserved identifier `_`" thing), so you can't really call it a
regression; it could be fixed in a separate PR.

Resolves rust-lang#78511.
m-ou-se added a commit to m-ou-se/rust that referenced this issue Jan 18, 2021
don't suggest erroneous trailing comma after `..`

In rust-lang#76612, suggestions were added for missing fields in patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the last field. This resulted in the "if you don't care about missing fields" suggestion to recommend code with a trailing comma after the field ellipsis (`..,`), which is actually not legal ("`..` must be at the end and cannot have a trailing comma")!

Incidentally, the doc-comment on `error_unmentioned_fields` was using `you_cant_use_this_field` as an example field name (presumably copy-paste inherited from the description of Issue rust-lang#76077), but the present author found this confusing, because unmentioned fields aren't necessarily unusable.

The suggested code in the diff this commit introduces to `destructuring-assignment/struct_destructure_fail.stderr` doesn't work, but it didn't work beforehand, either (because of the "found reserved identifier `_`" thing), so you can't really call it a regression; it could be fixed in a separate PR.

Resolves rust-lang#78511.

r? `@davidtwco` or `@estebank`
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 19, 2021
don't suggest erroneous trailing comma after `..`

In rust-lang#76612, suggestions were added for missing fields in patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the last field. This resulted in the "if you don't care about missing fields" suggestion to recommend code with a trailing comma after the field ellipsis (`..,`), which is actually not legal ("`..` must be at the end and cannot have a trailing comma")!

Incidentally, the doc-comment on `error_unmentioned_fields` was using `you_cant_use_this_field` as an example field name (presumably copy-paste inherited from the description of Issue rust-lang#76077), but the present author found this confusing, because unmentioned fields aren't necessarily unusable.

The suggested code in the diff this commit introduces to `destructuring-assignment/struct_destructure_fail.stderr` doesn't work, but it didn't work beforehand, either (because of the "found reserved identifier `_`" thing), so you can't really call it a regression; it could be fixed in a separate PR.

Resolves rust-lang#78511.

r? `@davidtwco` or `@estebank`
@jalcine
Copy link

jalcine commented Mar 20, 2021

Thankfully, I landed here from a Web search and then found https://steveklabnik.com/writing/structure-literals-vs-constructors-in-rust as a way to counteract this. Hope this helps anyone else who comes across this.

(Originally published at: https://v2.jacky.wtf/post/5bf98ed9-e8a1-46ca-9e26-245230276048)

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 C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants