rust/tests/ui/block-result/issue-20862.stderr

error[E0308]: mismatched types
  --> $DIR/issue-20862.rs:2:5
   |
LL | fn foo(x: i32) {
   |               - help: a return type might be missing here: `-> _`
LL |     |y| x + y
   |     ^^^^^^^^^ expected `()`, found closure
   |
   = note: expected unit type `()`
                found closure `{closure@$DIR/issue-20862.rs:2:5: 2:8}`

error[E0618]: expected function, found `()`
  --> $DIR/issue-20862.rs:7:13
   |
LL | fn foo(x: i32) {
   | -------------- `foo` defined here returns `()`
...
LL |     let x = foo(5)(2);
   |             ^^^^^^---
   |             |
   |             call expression requires function

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0308, E0618.
For more information about an error, try `rustc --explain E0308`.
Move tests to `ui` 2017-06-23 19:43:35 -05:00			`error[E0308]: mismatched types`
Remove licenses 2018-12-25 09:56:47 -06:00			`--> $DIR/issue-20862.rs:2:5`
Move tests to `ui` 2017-06-23 19:43:35 -05:00			`\|`
Update UI tests 2018-02-22 18:42:32 -06:00			`LL \| fn foo(x: i32) {`
Point to where missing return type should go 2023-09-30 14:29:41 -05:00			\| - help: a return type might be missing here: `-> _`
Update UI tests 2018-02-22 18:42:32 -06:00			`LL \| \|y\| x + y`
Surround types with backticks in type errors 2019-11-15 11:37:01 -06:00			\| ^^^^^^^^^ expected `()`, found closure
Move tests to `ui` 2017-06-23 19:43:35 -05:00			`\|`
review comments: tweak prefix strings 2019-11-14 16:08:08 -06:00			= note: expected unit type `()`
adjust how closure/generator types and rvalues are printed 2023-09-09 01:36:50 -05:00			found closure `{closure@$DIR/issue-20862.rs:2:5: 2:8}`
Move tests to `ui` 2017-06-23 19:43:35 -05:00
			error[E0618]: expected function, found `()`
Remove licenses 2018-12-25 09:56:47 -06:00			`--> $DIR/issue-20862.rs:7:13`
Move tests to `ui` 2017-06-23 19:43:35 -05:00			`\|`
Use smaller def span for functions Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata. 2020-08-12 16:02:14 -05:00			`LL \| fn foo(x: i32) {`
			\| -------------- `foo` defined here returns `()`
in which the E0618 "expected function" diagnostic gets a makeover Now the main span focuses on the erroneous not-a-function callee, while showing the entire call expression is relegated to a secondary span. In the case where the erroneous callee is itself a call, we point out the definition, and, if the call expression spans multiple lines, tentatively suggest a semicolon (because we suspect that the "outer" call is actually supposed to be a tuple). The new `bug!` assertion is, in fact, safe (`confirm_builtin_call` is only called by `check_call`, which is only called with a first arg of kind `ExprKind::Call` in `check_expr_kind`). Resolves #51055. 2018-11-10 22:46:05 -06:00			`...`
Use smaller def span for functions Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata. 2020-08-12 16:02:14 -05:00			`LL \| let x = foo(5)(2);`
			`\| ^^^^^^---`
			`\| \|`
			`\| call expression requires function`
Move tests to `ui` 2017-06-23 19:43:35 -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 2 previous errors`
Move tests to `ui` 2017-06-23 19:43:35 -05:00
hide `--explain` hint if error has no extended info 2019-04-17 12:26:38 -05:00			`Some errors have detailed explanations: E0308, E0618.`
update tests 2018-03-03 08:59:40 -06:00			For more information about an error, try `rustc --explain E0308`.