Improve error locations for return type errors

[Andarist]

Suggestion

🔍 Search Terms

error return type location squiggles

✅ 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

I propose to move the error location for return type error to the return keyword of the return statement.

At the moment the whole return statement gets underlined. In almost every case that is longer than 1 LOC it feels very overwhelming. At the moment I'm looking at this:

It makes it hard to focus on what is actually underlined here - it's not even immediately obvious that this complains about the type of this expression not being assignable to the declared return type. The first instinct tell me to look into the expressions itself (since it's a call expression) and look for some errors in it - it doesn't exactly point my mind to thinking about the failed assignability check with the declared return type. And even when I finally recognize the true problem - it's distracting and it makes it harder (for me) to focus on the problem.

If we compare this with assignability errors reported on variable declarations it also feels somewhat inconsistent:

const a: string = 10
//    ^
function test(): string {
    return 10
//  ^^^^^^^^^    
}

With the variable declaration only the "target" of the assignment gets highlighted. That target is almost guaranteed to be short(ish) as that's just an identifier. So this error just can't span multiple lines.

What I'm proposing is to change the error location to this:

function test(): string {
    return 10
//  ^^^^^^    
}

cc @DanielRosenwasser , i think i recall some similar issues created by you (but perhaps about other locations) but I can't find them now

[jakebailey]

I feel like sticking it onto the return keyword is fine, if only because some cases of error locations for non-assignability also use a smaller range: Playground Link

[fatcerberus]

It looks like the general rule is that the error span is always on the innermost offending assignment target (object property, variable, etc.), except when that's impossible because the assignment target isn't explicitly part of syntax, e.g. function arguments, in which case it highlights the source value. return is a notable outlier in that it highlights both the assignment target (return) and the source.

[DanielRosenwasser]

Thanks @Andarist!