Improve error message for type mismatch in generator arguments #88911
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit cbd7983 has been approved by |
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 16, 2021
…nkov Improve error message for type mismatch in generator arguments Fixes rust-lang#88653. The code example given there is invalid because the `Generator` trait (unlike the `Fn` traits) does not take the generator arguments in tupled-up form (because there can only be one argument, from my understanding). Hence, the type error in the example in rust-lang#88653 is correct, because the given generator takes a `bool` argument, whereas the function's return type talks about a generator with a `(bool,)` argument. The error message is both confusing and wrong, though: It is wrong because it displays the wrong "expected signature", and it is confusing because both the "expected" and "found" notes point at the same span. With my changes, I get the following, more helpful output: ``` error[E0631]: type mismatch in generator arguments --> test.rs:5:22 | 5 | fn foo(bar: bool) -> impl Generator<(bool,)> { | ^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `fn((bool,)) -> _` 6 | |bar| { | ----- found signature of `fn(bool) -> _` ```
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 17, 2021
Rollup of 10 pull requests Successful merges: - rust-lang#86382 (Make diagnostics clearer for `?` operators) - rust-lang#87529 (Fix ICE in `improper_ctypes_definitions` lint with all-ZST transparent types) - rust-lang#88339 (Add TcpListener::into_incoming and IntoIncoming) - rust-lang#88735 (Don't lint about missing code examples in derived traits) - rust-lang#88751 (Couple of changes to FileSearch and SearchPath) - rust-lang#88883 (Move some tests to more reasonable directories - 7) - rust-lang#88887 (Const Deref) - rust-lang#88911 (Improve error message for type mismatch in generator arguments) - rust-lang#89014 (PassWrapper: handle separate Module*SanitizerPass) - rust-lang#89033 (Set the library path in sysroot-crates-are-unstable) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #88653. The code example given there is invalid because the
Generatortrait (unlike theFntraits) does not take the generator arguments in tupled-up form (because there can only be one argument, from my understanding). Hence, the type error in the example in #88653 is correct, because the given generator takes aboolargument, whereas the function's return type talks about a generator with a(bool,)argument.The error message is both confusing and wrong, though: It is wrong because it displays the wrong "expected signature", and it is confusing because both the "expected" and "found" notes point at the same span. With my changes, I get the following, more helpful output: