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

Potentially misleading compiler error for unfinished line with Option<T> #25133

Closed
DoumanAsh opened this issue May 5, 2015 · 5 comments · Fixed by #43484
Closed

Potentially misleading compiler error for unfinished line with Option<T> #25133

DoumanAsh opened this issue May 5, 2015 · 5 comments · Fixed by #43484
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

@DoumanAsh
Copy link

Next code:

use std::io::{Read, stdin};

fn main() {
    stdin().bytes().next()
}

Gives this compile error:

E:\Downloads\Git\collectionScripts\rust
 [master +2 ~1 -0 !] > rustc.exe .\temp.rs
.\temp.rs:4:5: 4:27 error: mismatched types:
 expected `()`,
    found `core::option::Option<core::result::Result<u8, std::io::error::Error>>`
(expected (),
    found enum `core::option::Option`) [E0308]
.\temp.rs:4     stdin().bytes().next()
                ^~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

Which is a bit misleading as there is actually we're missing either ; or unwrap() i think?

Rust version:

rustc 1.0.0-beta.4 (850151a75 2015-04-30) (built 2015-05-01)
binary: rustc
commit-hash: 850151a75709f146addd30bbbf1f23d384f0b381
commit-date: 2015-04-30
build-date: 2015-05-01
host: x86_64-pc-windows-gnu
release: 1.0.0-beta.4
@frewsxcv
Copy link
Member

frewsxcv commented May 5, 2015

fn main() { } is a function that expects nothing (()) to be returned. In your code block, since that statement doesn't end in a ;, it is going to try to return the result of it to the function.

@sinistersnare
Copy link
Contributor

I agree, error messages for wrong function return types should be better.

I would expect something like

fn main is marked as returning (), however returns Option

or something like that.

@DoumanAsh
Copy link
Author

Oh.. i actually did not notice it at the beginning. Originally i had this problem in a bit more bigger code block.
I think it would be good to point that it is being return type of function so that it would be more clear to user why compiler is angry

@steveklabnik steveklabnik added I-papercut A-diagnostics Area: Messages for errors, warnings, and lints labels May 7, 2015
@steveklabnik
Copy link
Member

Triage: main's diagnostics have a long history, #35946 for example, and all of the try! stuff before that. Looks like there's a PR for this issue.

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum
Copy link
Member

I think the semicolon suggestion we give today is a good start, but indicating that the cause of the expected type is the function's return type would be even better.

error[E0308]: mismatched types
 --> test.rs:4:5
  |
4 |     stdin().bytes().next()
  |     ^^^^^^^^^^^^^^^^^^^^^^- help: did you mean to add a semicolon here?: `;`
  |     |
  |     expected (), found enum `std::option::Option`
  |
  = note: expected type `()`
             found type `std::option::Option<std::result::Result<u8, std::io::Error>>`

error: aborting due to previous error

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 22, 2017
estebank added a commit to estebank/rust that referenced this issue Jul 26, 2017
Before this, the diagnostic errors would only point at the return type
when changing it would be a possible solution to a type error. Add a
label to the return type without a suggestion to change in order to make
the source of the expected type obvious.

Follow up to rust-lang#42850, fixes rust-lang#25133, fixes rust-lang#41897.
bors added a commit that referenced this issue Aug 9, 2017
Point at return type always when type mismatch against it

Before this, the diagnostic errors would only point at the return type
when changing it would be a possible solution to a type error. Add a
label to the return type without a suggestion to change in order to make
the source of the expected type obvious.

Follow up to #42850, fixes #25133, fixes #41897.
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

Successfully merging a pull request may close this issue.

5 participants