nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-30 10:45:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
8c66e117e2
rust/tests/ui/async-await/generator-desc.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

54 lines
2.0 KiB
Plaintext
Raw Normal View History

name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
error[E0308]: mismatched types
Avoid `GenFuture` shim when compiling async constructs Previously, async constructs would be lowered to "normal" generators, with an additional `from_generator` / `GenFuture` shim in between to convert from `Generator` to `Future`. The compiler will now special-case these generators internally so that async constructs will *directly* implement `Future` without the need to go through the `from_generator` / `GenFuture` shim. The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.
2022-11-18 21:56:22 +00:00
--> $DIR/generator-desc.rs:10:19
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
|
LL | fun(async {}, async {});
Remove `identity_future` indirection This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm. Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
2022-11-24 16:58:32 +00:00
| --- -------- ^^^^^^^^ expected `async` block, found a different `async` block
| | |
| | the expected `async` block
| arguments to this function are incorrect
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
|
adjust how closure/generator types and rvalues are printed
2023-09-09 06:36:50 +00:00
= note: expected `async` block `{async block@$DIR/generator-desc.rs:10:9: 10:17}`
found `async` block `{async block@$DIR/generator-desc.rs:10:19: 10:27}`
Implementation for 65853 This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear.
2022-01-22 04:50:54 +00:00
note: function defined here
Remove `identity_future` indirection This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm. Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
2022-11-24 16:58:32 +00:00
--> $DIR/generator-desc.rs:8:4
|
LL | fn fun<F: Future<Output = ()>>(f1: F, f2: F) {}
| ^^^ -----
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
error[E0308]: mismatched types
--> $DIR/generator-desc.rs:12:16
|
LL | fun(one(), two());
fix: improve the suggestion on future not awaited Considering the following code ```rust fn foo() -> u8 { async fn async_fn() -> u8 { 22 } async_fn() } fn main() {} ``` the error generated before this commit from the compiler is ``` ➜ rust git:(macros/async_fn_suggestion) ✗ rustc test.rs --edition 2021 error[E0308]: mismatched types --> test.rs:4:5 | 1 | fn foo() -> u8 { | -- expected `u8` because of return type ... 4 | async_fn() | ^^^^^^^^^^ expected `u8`, found opaque type | = note: expected type `u8` found opaque type `impl Future<Output = u8>` help: consider `await`ing on the `Future` | 4 | async_fn().await | ++++++ error: aborting due to previous error ``` In this case the error is nor perfect, and can confuse the user that do not know that the opaque type is the future. So this commit will propose (and conclude the work start in https://github.com/rust-lang/rust/issues/80658) to change the string `opaque type` to `future` when applicable and also remove the Expected vs Received note by adding a more specific one regarding the async function that return a future type. So the new error emitted by the compiler is ``` error[E0308]: mismatched types --> test.rs:4:5 | 1 | fn foo() -> u8 { | -- expected `u8` because of return type ... 4 | async_fn() | ^^^^^^^^^^ expected `u8`, found future | note: calling an async function returns a future --> test.rs:4:5 | 4 | async_fn() | ^^^^^^^^^^ help: consider `await`ing on the `Future` | 4 | async_fn().await | ++++++ error: aborting due to previous error ``` Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2023-02-10 18:03:54 +00:00
| --- ^^^^^ expected future, found a different future
Implementation for 65853 This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear.
2022-01-22 04:50:54 +00:00
| |
| arguments to this function are incorrect
Tweak opaque type mismatch error
2021-07-31 19:20:00 +00:00
|
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
= help: consider `await`ing on both `Future`s
= note: distinct uses of `impl Trait` result in different opaque types
Implementation for 65853 This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear.
2022-01-22 04:50:54 +00:00
note: function defined here
--> $DIR/generator-desc.rs:8:4
|
LL | fn fun<F: Future<Output = ()>>(f1: F, f2: F) {}
Point out a single arg if we have a single arg incompatibility
2022-07-23 17:17:19 +00:00
| ^^^ -----
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
error[E0308]: mismatched types
--> $DIR/generator-desc.rs:14:26
|
LL | fun((async || {})(), (async || {})());
Resolve vars in note_type_err
2022-04-17 19:00:32 +00:00
| --- -- ^^^^^^^^^^^^^^^ expected `async` closure body, found a different `async` closure body
| | |
| | the expected `async` closure body
Implementation for 65853 This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear.
2022-01-22 04:50:54 +00:00
| arguments to this function are incorrect
Remove trailing whitespace from error messages
2021-06-10 11:52:00 +00:00
|
adjust how closure/generator types and rvalues are printed
2023-09-09 06:36:50 +00:00
= note: expected `async` closure body `{async closure body@$DIR/generator-desc.rs:14:19: 14:21}`
found `async` closure body `{async closure body@$DIR/generator-desc.rs:14:36: 14:38}`
Implementation for 65853 This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear.
2022-01-22 04:50:54 +00:00
note: function defined here
--> $DIR/generator-desc.rs:8:4
|
LL | fn fun<F: Future<Output = ()>>(f1: F, f2: F) {}
Point out a single arg if we have a single arg incompatibility
2022-07-23 17:17:19 +00:00
| ^^^ -----
name async generators something more human friendly in type error diagnostics
2021-01-29 02:16:52 +00:00
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0308`.
Reference in New Issue Copy Permalink