Add quick fix to add missing 'await'

[andrewbranch]

Fixes #30646

Most of this PR is not terribly interesting, so let me point out the interesting parts:

1. I’m currently not limiting the quick fix to async functions, based on a couple things: a) our pre-existing usage of the message “Did you forget to use 'await'?” was not predicated on being in an async function, and b), if you add await inside a non-async function, we’ll immediately surface a subsequent code fix to add async to the function, which I predict will be a common and convenient sequence. So right now, I’ve limited the quick fix to appearing when the await would go inside a function/arrow/method body (something that can take async).
2. When problem-Promise is a variable who has a declaration with an initializer in the same file that is not exported, and that variable is not yet used anywhere else, and the variable does not have a declared type, we offer two code fixes: the first in the list is to add await to the initializer of the variable at the declaration site. The second is the standard insertion of await at the use site, as is available everywhere else. When applying “Fix all expressions possibly missing 'await',” the initializer fix is preferred if available.

[sandersn]

Code looks good, but it looks like this fix shows for any incorrect addition, like number + HTMLElement, and then proceeds to do nothing when invoked. Did you think about making specific errors for + et al when one of the sides is a Promise? That would make the codefix suggestion quite a bit more accurate. What do you think?

[sandersn]

This will show for any old type combination, like number + Event, right? What happens in that case? Does it just fail to do anything when you try to "add missing await"?

[andrewbranch]

It's supposed to be filtered out further in getCodeActions (it doesn’t show anything if you return undefined / empty array in there). This is back to the tradeoffs we were discussing about using related info as a “bonus error message” vs. copying and pasting all these into new, unique messages. I wrote this down as a larger LS design/API change to consider at some later point.

[andrewbranch]

Code looks good, but it looks like this fix shows for any incorrect addition, like number + HTMLElement, and then proceeds to do nothing when invoked. Did you think about making specific errors for + et al when one of the sides is a Promise? That would make the codefix suggestion quite a bit more accurate. What do you think?

Hum, yes, I did think about it, but it should be handled by isMissingAwaitError. Something is amiss. (Related, I had a discussion with Wes in Teams about how VS Code doesn’t request code fixes for related info error codes, which would make this much cleaner. I’m thinking about PRing them to suggest a change there.)

[andrewbranch]

but it looks like this fix shows for any incorrect addition, like number + HTMLElement

Ah, I thought you were saying you observed this happening, but I think you were just looking at the error codes? I believe it’s working correctly, but I just pushed a test for that negative case specifically. It’s a good thing to assert in the tests.

I gave some more context about what’s happening and why I took this approach in the inline comments, but TL;DR, the error codes are necessary but not sufficient to surface a quick fix. Once getCodeActions is invoked with a possible candidate, it correlates the error with the related message Did you forget to use 'await'? that the checker added via semantic knowledge that there’s a strong chance await is appropriate (#32239). If it doesn’t find that, it bails, and a code fix doesn’t show.

[sandersn]

Nope, I didn't run it, just read the code. I think I was thinking of the refactor API instead of the codefix API? IIRC the refactor API is the one with two calls, and the first one has to be fast because it runs a lot.