2020-02-21 03:53:32 +00:00
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:5:28
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S0<T> {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - expected this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
LL | const C: S0<u8> = Self(0);
|
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
|
|
|
| ---- ^ expected type parameter `T`, found integer
|
|
|
|
|
| |
|
|
|
|
|
| arguments to this function are incorrect
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected type parameter `T`
|
|
|
|
|
found type `{integer}`
|
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: tuple struct defined here
|
|
|
|
|
--> $DIR/issue-69306.rs:3:8
|
|
|
|
|
|
|
|
|
|
|
LL | struct S0<T>(T);
|
|
|
|
|
| ^^
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:5:23
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S0<T> {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - found this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
LL | const C: S0<u8> = Self(0);
|
2023-01-03 02:00:33 +00:00
|
|
|
| ^^^^^^^ expected `S0<u8>`, found `S0<T>`
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected struct `S0<u8>`
|
|
|
|
|
found struct `S0<T>`
|
|
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:10:14
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S0<T> {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - expected this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
...
|
|
|
|
|
LL | Self(0);
|
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
|
|
|
| ---- ^ expected type parameter `T`, found integer
|
|
|
|
|
| |
|
|
|
|
|
| arguments to this function are incorrect
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected type parameter `T`
|
|
|
|
|
found type `{integer}`
|
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: tuple struct defined here
|
|
|
|
|
--> $DIR/issue-69306.rs:3:8
|
|
|
|
|
|
|
|
|
|
|
LL | struct S0<T>(T);
|
|
|
|
|
| ^^
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:27:14
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> Foo<T> for <S0<T> as Fun>::Out {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - expected this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
LL | fn foo() {
|
|
|
|
|
LL | Self(0);
|
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
|
|
|
| ---- ^ expected type parameter `T`, found integer
|
|
|
|
|
| |
|
|
|
|
|
| arguments to this function are incorrect
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected type parameter `T`
|
|
|
|
|
found type `{integer}`
|
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: tuple struct defined here
|
|
|
|
|
--> $DIR/issue-69306.rs:3:8
|
|
|
|
|
|
|
|
|
|
|
LL | struct S0<T>(T);
|
|
|
|
|
| ^^
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:33:32
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S1<T, u8> {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - expected this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
LL | const C: S1<u8, u8> = Self(0, 1);
|
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
|
|
|
| ---- ^ expected type parameter `T`, found integer
|
|
|
|
|
| |
|
|
|
|
|
| arguments to this function are incorrect
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected type parameter `T`
|
|
|
|
|
found type `{integer}`
|
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: tuple struct defined here
|
|
|
|
|
--> $DIR/issue-69306.rs:31:8
|
|
|
|
|
|
|
|
|
|
|
LL | struct S1<T, U>(T, U);
|
|
|
|
|
| ^^
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:33:27
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S1<T, u8> {
|
2023-10-18 22:10:48 +00:00
|
|
|
| - found this type parameter
|
2020-02-21 03:53:32 +00:00
|
|
|
LL | const C: S1<u8, u8> = Self(0, 1);
|
2023-01-03 02:00:33 +00:00
|
|
|
| ^^^^^^^^^^ expected `S1<u8, u8>`, found `S1<T, u8>`
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected struct `S1<u8, _>`
|
|
|
|
|
found struct `S1<T, _>`
|
|
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:41:14
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S2<T> {
|
|
|
|
|
| - expected type parameter
|
|
|
|
|
LL | fn map<U>(x: U) -> S2<U> {
|
|
|
|
|
| - found type parameter
|
|
|
|
|
LL | Self(x)
|
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
|
|
|
| ---- ^ expected type parameter `T`, found type parameter `U`
|
|
|
|
|
| |
|
|
|
|
|
| arguments to this function are incorrect
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected type parameter `T`
|
|
|
|
|
found type parameter `U`
|
|
|
|
|
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
|
|
|
|
|
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
|
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: tuple struct defined here
|
|
|
|
|
--> $DIR/issue-69306.rs:38:8
|
|
|
|
|
|
|
|
|
|
|
LL | struct S2<T>(T);
|
|
|
|
|
| ^^
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
error[E0308]: mismatched types
|
|
|
|
|
--> $DIR/issue-69306.rs:41:9
|
|
|
|
|
|
|
|
|
|
|
LL | impl<T> S2<T> {
|
|
|
|
|
| - found type parameter
|
|
|
|
|
LL | fn map<U>(x: U) -> S2<U> {
|
|
|
|
|
| - ----- expected `S2<U>` because of return type
|
|
|
|
|
| |
|
|
|
|
|
| expected type parameter
|
|
|
|
|
LL | Self(x)
|
2023-01-03 02:00:33 +00:00
|
|
|
| ^^^^^^^ expected `S2<U>`, found `S2<T>`
|
2020-02-21 03:53:32 +00:00
|
|
|
|
|
|
|
|
|
= note: expected struct `S2<U>`
|
|
|
|
|
found struct `S2<T>`
|
|
|
|
|
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
|
|
|
|
|
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
|
|
|
|
|
|
|
|
|
|
error: aborting due to 8 previous errors
|
|
|
|
|
|
|
|
|
|
For more information about this error, try `rustc --explain E0308`.
|