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

diagnostics: rustc displays confusing Ok(#[stable(feature = "rust1", since = "1.0.0")] T) if wrong match binding is used #74673

Open
matthiaskrgr opened this issue Jul 23, 2020 · 1 comment
Labels
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.

Comments

@matthiaskrgr
Copy link
Member

matthiaskrgr commented Jul 23, 2020

If I have a function that returns Result<(), i32> and try to match on it with Ok() instead of Ok(()) or Ok(_), I get an error:

error[E0023]: this pattern has 0 fields, but the corresponding tuple variant has 1 field
   --> src/main.rs:7:9
    |
7   |         Ok() => {}
    |         ^^^^ expected 1 field, found 0
    |
   ::: /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/result.rs:250:5
    |
250 |     Ok(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     --------------------------------------------------- tuple variant defined here
    |
help: missing parenthesis
    |
7   |         Ok(()) => {}
    |           ^  ^

error: aborting due to previous error

The Ok(#[stable(feature = "rust1", since = "1.0.0")] T), comes from std but I think it can look very confusing to beginners, a simple Ok(T) would be much clearer here imo.

code:

fn a() -> Result<(), i32> {
    Ok(())
}

fn main() {
    match a() {
        Ok() => {} // should be: Ok(()) or Ok(_)
        Err(_) => {}
    }
}
binary: rustc
commit-hash: 346aec9b02f3c74f3fce97fd6bda24709d220e49
commit-date: 2020-07-11
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0
@JohnTitor JohnTitor 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 Jul 23, 2020
@estebank
Copy link
Contributor

Cc #65515

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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants