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

Mistyping <> in return value for () could have better error message #18945

Closed
mdinger opened this issue Nov 14, 2014 · 8 comments
Closed

Mistyping <> in return value for () could have better error message #18945

mdinger opened this issue Nov 14, 2014 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mdinger
Copy link
Contributor

mdinger commented Nov 14, 2014

This errors but doesn't point out the problem very well:

fn fun() -> Option<int> {
    Some<7>
}
fn main(){ 
    fun();
}

The error:

<anon>:4:1: 4:2 error: unexpected token: `}`
<anon>:4 }
         ^
playpen: application terminated with error code 101

Better would be:

fn fun() -> Option<int> {
    Some<7>
    //  ^~~~~~~ These should be `()` and not`<>`
}
@nodakai
Copy link
Contributor

nodakai commented Nov 14, 2014

I guess rustc thought Some<7> was two comparison expressions (the second one lacks the right hand side). The parser didn't know Some could resolve to an enum constructor with arity 1. Just a speculation, though.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 27, 2015
@steveklabnik
Copy link
Member

This error is much better now:

hello.rs:2:13: 3:2 error: chained comparison operators require parentheses
hello.rs:2         Some<7>
hello.rs:3 }
hello.rs:2:13: 3:2 help: use `::<...>` instead of `<...>` if you meant to specify type arguments
hello.rs:3:1: 3:2 error: unexpected token: `}`
hello.rs:3 }
           ^~

but still not as helpful as it could be.

@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 Mark-Simulacrum added the A-parser Area: The parsing of Rust source code to an AST label May 30, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 22, 2017
@estebank
Copy link
Contributor

estebank commented Sep 21, 2017

Full current output:

error: chained comparison operators require parentheses
 --> src/main.rs:2:9
  |
2 |       Some<7>
  |  _________^
3 | | }
  | |_^
  |
  = help: use `::<...>` instead of `<...>` if you meant to specify type arguments

error: expected expression, found `}`
 --> src/main.rs:3:1
  |
3 | }
  | ^

error[E0308]: mismatched types
 --> src/main.rs:1:27
  |
1 |   fn fun() -> Option<usize> {
  |  ___________________________^
2 | |     Some<7>
3 | | }
  | |_^ expected enum `std::option::Option`, found ()
  |
  = note: expected type `std::option::Option<usize>`
             found type `()`

I believe that this ticket is asking for a generic diagnostic check to look code that seems to be setting a type argument on a fn, fn struct or a fn enum variant, but in libsyntax/parse/parser.rs you only have access to the Ident, not the type information in order to limit this suggestion only to fn-like types. A simple solution can be to expand the "type arguments" note to state

or use `(...)` if you meant to specify fn arguments

@estebank estebank added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. labels Sep 21, 2017
@jean-lourenco
Copy link
Contributor

@estebank I'd like to try and add that extra compile output that you mentioned.
I'll just need a little bit of time to figure out how to test it, as I'm fairly new to Rust and this project. I've made the change and builded the solution, but the output is still the same. (Probably using the wrong binaries to test or something)

@estebank
Copy link
Contributor

estebank commented Oct 6, 2017

It's great @jean-lourenco! Make sure you build using ./x.py build --stage 1, and you'll find the binary in build/x86_64-apple-darwin/stage1/bin/rustc. You can also use ./x.py test --stage 1 src/test, go get coffee and see if any test actually fails after your modification.

kennytm added a commit to kennytm/rust that referenced this issue Oct 11, 2017
Better compile error output when using arguments instead of types

Following @estebank sugestion on issue rust-lang#18945 (comment)
kennytm added a commit to kennytm/rust that referenced this issue Oct 12, 2017
Better compile error output when using arguments instead of types

Following @estebank sugestion on issue rust-lang#18945 (comment)
kennytm added a commit to kennytm/rust that referenced this issue Oct 13, 2017
Better compile error output when using arguments instead of types

Following @estebank sugestion on issue rust-lang#18945 (comment)
@colinmarsh19
Copy link
Contributor

Is this issue still being worked on? @jean-lourenco @estebank @kennytm

@jean-lourenco
Copy link
Contributor

@colinmarsh19 the lastest suggestion by @estebank in #18945 (comment) was done on #45122.

If there're no more comments/suggestions on the issue, I think it's pretty much done.

@estebank
Copy link
Contributor

estebank commented Nov 8, 2017

Closing as I see very little to improve specific to this, other than the span pointing at Some<7> }.

@estebank estebank closed this as completed Nov 8, 2017
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 A-parser Area: The parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. 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

8 participants