Mention "return type" in the error message when return type of a function is not matching the declared type

[mohsen1]

Suggestion

🔍 Search Terms

return type, error message

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Mention "return type" when return type of a function is not matching the declared type

When a parameter type is not matching the declared type, the error message has the words "parameter X" in it which makes it super easy to spot the error. For return types it only says type X is not compatible with type Y but is not clear that it is the return type

📃 Motivating Example

Playground

const func: (a: string, very: number, confusing: string, error: boolean, message: string) => string = 
    (a: string, very: number, confusing: string, error: boolean, message: string) => {
        return 1
    }

Error:

Type '(a: string, very: number, confusing: string, error: boolean, message: string) => number' is not assignable to type '(a: string, very: number, confusing: string, error: boolean, message: string) => string'.
  Type 'number' is not assignable to type 'string'.(2322)

💻 Use Cases

This can get tricky in very large and complex types. Just mentioning the word "return" can save a ton of time debugging issues

[RyanCavanaugh]

If someone wants a good project, I think any time we have

X is not assignable to Y
  A is not assignable to B

there's a "missing" elaboration:

X is not assignable to Y
  (Some explanatory text of why we're talking about A and B)
    A is not assignable to B

[bakkot]

Drive-by comment since I was just looking at this code: there actually is already a diagnostic for this, which you can trigger with this example I've reduced from a test.

It's just getting suppressed, or somehow not getting triggered, in other cases. Possibly it has to do with the elidedInCompatabilityPyramid attribute which is true only for those specific return-type diagnostic messages (and no others), or with the logic in reportIncompatibleStack which switches on those diagnostics explicitly? I don't have any insight there; I just wanted to mention the existence of those diagnostics.

[gmanninglive]

This is interesting, a little investigation and the Diagnostics @bakkot mentions were suppressed in #33473

Removing the "elidedInCompatabilityPyramid": true attribute gives a more readable message and doesn't cause the long pyramid on the example in #33361

I feel like these 4 messages could be flattened into one simpler message

"Call signature return types '{0}' and '{1}' are incompatible.": {
        "category": "Error",
        "code": 2202,
        "elidedInCompatabilityPyramid": true
    },
    "Construct signature return types '{0}' and '{1}' are incompatible.": {
        "category": "Error",
        "code": 2203,
        "elidedInCompatabilityPyramid": true
    },
    "Call signatures with no arguments have incompatible return types '{0}' and '{1}'.": {
        "category": "Error",
        "code": 2204,
        "elidedInCompatabilityPyramid": true
    },
    "Construct signatures with no arguments have incompatible return types '{0}' and '{1}'.": {
        "category": "Error",
        "code": 2205,
        "elidedInCompatabilityPyramid": true
    },

especially as the with no arguments variants are already merged in the checker...

  if (msg.code === Diagnostics.Call_signatures_with_no_arguments_have_incompatible_return_types_0_and_1.code) {
                                mappedMsg = Diagnostics.Call_signature_return_types_0_and_1_are_incompatible;
                            }
                            else if (msg.code === Diagnostics.Construct_signatures_with_no_arguments_have_incompatible_return_types_0_and_1.code) {
                                mappedMsg = Diagnostics.Construct_signature_return_types_0_and_1_are_incompatible;
                            }

Also there is another related diagnostic

    "The expected type comes from the return type of this signature.": {
        "category": "Message",
        "code": 6502
    },

That seems to trigger with an implicit return, but not with explicit return or if redefining the type on the args

Playground example