Sourcemap for async function with target es2015 has missing line

Bug Report

Async functions are downleveled to a generator, using the __awaiter wrapper.
If an async function throws an exception, the stack trace includes the call to __awaiter and then the internals of __awaiter in the following frames. The problem is with how to map those to source code.

Using importHelpers and noEmitHelpers helps with producing stable stack frames for the __awaiter internals, that can be mapped back to tslib.
However, the very call to __awaiter in my app code is still inlined, and it currently doesn't have any mapping.

This makes it a problem with tools that rely on stable stack traces. Logging tools, such as Sentry, heavily use mapped stack traces to group multiple occurrences of the same error into a single bucket. Inability to map some frames prevents such grouping, which results in all sorts of problems when monitoring the app in production (false alarms, noise on the dashboard).

Similar issues about async sourcemaps - which I still believe describe different problems than mine:

• https://github.com/microsoft/TypeScript/issues/13522
• https://github.com/microsoft/TypeScript/issues/14506

🔎 Search Terms

sourcemap, async, awaiter, generator

🕗 Version & Regression Information

I tested it in 3.5, 4.2 and 4.3. Probably it has always been the case.

⏯ Playground Link

Playground link with relevant code

Here I enabled source maps. If you decode it, you can see that there is no mapping for line (2) (the __awaiter(this, void 0, void 0, function* () call). Yet, this line is present in the stack trace.

💻 Code

// original.ts

async function callAsync() {
  throw new Error('sync')
}

callAsync()

// compiled.js

function callAsync() {
    return __awaiter(this, void 0, void 0, function* () { // <----- This line (2) is present in error stack trace
        throw new Error('sync');
    });
}
callAsync();

🙁 Actual behavior

Stack trace includes line (2) (the one with the awaiter call). However, the sourcemap doesn't have a mapping for this line

🙂 Expected behavior

I don't know, frankly. Why don't we map this line to the declaration of our async function (source line 1)? Or to the declaration of the awaiter helper?

Reproduce the case from original.ts and compiled.js using the linked Playground configuration, then decode the inline source map and compare it with the stack-trace line for the __awaiter call. Clarify the intended mapping target for that line and verify the resulting mapping under an ES2015 target with importHelpers and noEmitHelpers enabled.