mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8674efdb7c
rust/src/test/ui/span/issue-34264.stderr

73 lines
2.2 KiB
Plaintext
Raw Normal View History

parser: gracefully handle `fn foo(A | B: type)`.
2019-08-24 21:39:28 -05:00
error: expected one of `:`, `@`, or `|`, found `<`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:1:14
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | fn foo(Option<i32>, String) {}
Remove "here" from "expected one of X here"
2019-10-28 13:08:53 -05:00
| ^ expected one of `:`, `@`, or `|`
syntax: improve parameter without type suggestions This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types, which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only `,` and `)` or trait items), this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap<u32>)` -> `fn foo(HashMap: TypeName<u32>)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood <david@davidtw.co>
2019-10-01 09:17:50 -05:00
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a type, explicitly ignore the parameter name
|
LL | fn foo(_: Option<i32>, String) {}
| ^^^^^^^^^
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
parser: gracefully handle `fn foo(A | B: type)`.
2019-08-24 21:39:28 -05:00
error: expected one of `:`, `@`, or `|`, found `)`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:1:27
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | fn foo(Option<i32>, String) {}
Remove "here" from "expected one of X here"
2019-10-28 13:08:53 -05:00
| ^ expected one of `:`, `@`, or `|`
Recover gracefully from argument with missing type or param name
2019-05-29 17:25:46 -05:00
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this was a parameter name, give it a type
|
LL | fn foo(Option<i32>, String: TypeName) {}
| ^^^^^^^^^^^^^^^^
help: if this is a type, explicitly ignore the parameter name
|
LL | fn foo(Option<i32>, _: String) {}
| ^^^^^^^^^
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
parser: gracefully handle `fn foo(A | B: type)`.
2019-08-24 21:39:28 -05:00
error: expected one of `:`, `@`, or `|`, found `,`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:3:9
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | fn bar(x, y: usize) {}
Remove "here" from "expected one of X here"
2019-10-28 13:08:53 -05:00
| ^ expected one of `:`, `@`, or `|`
Recover gracefully from argument with missing type or param name
2019-05-29 17:25:46 -05:00
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this was a parameter name, give it a type
|
LL | fn bar(x: TypeName, y: usize) {}
| ^^^^^^^^^^^
help: if this is a type, explicitly ignore the parameter name
|
LL | fn bar(_: x, y: usize) {}
| ^^^^
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:7:5
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | fn foo(Option<i32>, String) {}
Point at whole method call instead of args To avoid confusion in cases where the code is ```rust fn foo() {} / foo( | bar() | ^^^ current diagnostics point here for arg count mismatch | ); |_^ new diagnostic span points here ``` as this leads to confusion making people think that the diagnostic is talking about `bar`'s arg count, not `foo`'s. Point at `fn`s definition on arg mismatch, just like we do for closures.
2017-12-10 13:12:17 -06:00
| --------------------------- defined here
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
...
Update tests
2019-03-09 06:03:44 -06:00
LL | foo(Some(42), 2, "");
Point at whole method call instead of args To avoid confusion in cases where the code is ```rust fn foo() {} / foo( | bar() | ^^^ current diagnostics point here for arg count mismatch | ); |_^ new diagnostic span points here ``` as this leads to confusion making people think that the diagnostic is talking about `bar`'s arg count, not `foo`'s. Point at `fn`s definition on arg mismatch, just like we do for closures.
2017-12-10 13:12:17 -06:00
| ^^^^^^^^^^^^^^^^^^^^ expected 2 parameters
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
error[E0308]: mismatched types
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:8:13
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | bar("", "");
Surround types with backticks in type errors
2019-11-15 11:37:01 -06:00
| ^^ expected `usize`, found `&str`
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-34264.rs:10:5
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | fn bar(x, y: usize) {}
Point at whole method call instead of args To avoid confusion in cases where the code is ```rust fn foo() {} / foo( | bar() | ^^^ current diagnostics point here for arg count mismatch | ); |_^ new diagnostic span points here ``` as this leads to confusion making people think that the diagnostic is talking about `bar`'s arg count, not `foo`'s. Point at `fn`s definition on arg mismatch, just like we do for closures.
2017-12-10 13:12:17 -06:00
| ------------------- defined here
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
...
Update tests
2019-03-09 06:03:44 -06:00
LL | bar(1, 2, 3);
Point at whole method call instead of args To avoid confusion in cases where the code is ```rust fn foo() {} / foo( | bar() | ^^^ current diagnostics point here for arg count mismatch | ); |_^ new diagnostic span points here ``` as this leads to confusion making people think that the diagnostic is talking about `bar`'s arg count, not `foo`'s. Point at `fn`s definition on arg mismatch, just like we do for closures.
2017-12-10 13:12:17 -06:00
| ^^^^^^^^^^^^ expected 2 parameters
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
report the total number of errors on compilation failure Prior to this PR, when we aborted because a "critical pass" failed, we displayed the number of errors from that critical pass. While that's the number of errors that caused compilation to abort in *that place*, that's not what people really want to know. Instead, always report the total number of errors, and don't bother to track the number of errors from the last pass that failed. This changes the compiler driver API to handle errors more smoothly, and therefore is a compiler-api-[breaking-change]. Fixes #42793.
2017-07-02 08:09:09 -05:00
error: aborting due to 6 previous errors
Introduce `TyErr` independent from `TyInfer` Add a `TyErr` type to represent unknown types in places where parse errors have happened, while still able to build the AST. Initially only used to represent incorrectly written fn arguments and avoid "expected X parameters, found Y" errors when called with the appropriate amount of parameters. We cannot use `TyInfer` for this as `_` is not allowed as a valid argument type. Example output: ```rust error: expected one of `:` or `@`, found `,` --> file.rs:12:9 | 12 | fn bar(x, y: usize) {} | ^ error[E0061]: this function takes 2 parameters but 3 parameters were supplied --> file.rs:19:9 | 12 | fn bar(x, y) {} | --------------- defined here ... 19 | bar(1, 2, 3); | ^^^^^^^ expected 2 parameters ```
2017-03-28 20:56:29 -05:00
hide `--explain` hint if error has no extended info
2019-04-17 12:26:38 -05:00
Some errors have detailed explanations: E0061, E0308.
update tests
2018-03-03 08:59:40 -06:00
For more information about an error, try `rustc --explain E0061`.
Reference in New Issue Copy Permalink