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

Error message shows type of private field #57320

Closed
killercup opened this issue Jan 3, 2019 · 3 comments · Fixed by #106600
Closed

Error message shows type of private field #57320

killercup opened this issue Jan 3, 2019 · 3 comments · Fixed by #106600
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@killercup
Copy link
Member

killercup commented Jan 3, 2019

The code below yields two errors:

  1. The field is private
  2. Type error in if expression because type is <type of private field> instead of bool

This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least.

Is this actually an issue? If you don't consider it one, feel free to close this.


fn main() {
    let x = foo::Foo::default();
    if x.len {
        println!("foo");
    }
}

mod foo {
    #[derive(Default)]
    pub struct Foo {
        len: String,
    }
    
    impl Foo {
        pub fn len(&self) -> usize {
            42
        }
    }
}

playground

(originally seen on reddit)

@killercup killercup added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 3, 2019
@estebank
Copy link
Contributor

estebank commented Jan 3, 2019

I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to
be a big problem.


Parsing x.len as x.len() when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of

error[E0616]: field `len` of struct `foo::Foo` is private
 --> src/main.rs:3:8
  |
3 |     if x.len {
  |        ^^^^^ help: a method `len` also exists, perhaps you wish to call it: `x.len()`

error[E0308]: mismatched types
 --> src/main.rs:3:8
  |
3 |     if x.len {
  |        ^^^^^ expected bool, found `usize`
  |
  = note: expected type `bool`
             found type `usize`
  = note: found `usize` assuming that `x.len` has been rewritten to `x.len()`

@estebank
Copy link
Contributor

Hi @rust-lang/wg-diagnostics! Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.

@davidtwco
Copy link
Member

Hi @rust-lang/wg-diagnostics! Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.

I agree, like you mentioned in a previous comment, there are some improvements we could make, but I think the current behaviour is fine.

@estebank estebank added P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 6, 2020
@crlf0710 crlf0710 added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 11, 2020
compiler-errors added a commit to compiler-errors/rust that referenced this issue Jan 9, 2023
…y-err, r=estebank

Suppress type errors that come from private fields

Fixes rust-lang#57320

There was some discussion here (rust-lang#57320 (comment)), but I honestly think the second error is worth suppressing regardless.

I would be open to feedback though -- perhaps we can suppress the `.len()` suggestion if there's type error (since we have access to [`Expectation`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/enum.Expectation.html), we can determine that).

r? `@estebank`
@bors bors closed this as completed in 29420a8 Jan 9, 2023
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. P-low Low priority 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