-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Awesome "help" message suggesting turbofish doesn't always appear #40396
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 15, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Point out correct turbofish usage on `Foo<Bar<Baz>>` Whenever we parse a chain of binary operations, as long as the first operation is `<` and the subsequent operations are either `>` or `<`, present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case. Fixes rust-lang#40396.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Actual behavior: When you compile this program,
this is the error message:
Expected behavior: If you trigger this error in a slightly different way,
you get a lovely "help" message at the end:
The bug is that the first program does not trigger this help message.
The text was updated successfully, but these errors were encountered: