Closure-compiler: loosing promise type when using await

[ikabirov]

async function foo() {
  let /** null */ x = await Promise.resolve(1); // no type warning
  Promise.resolve(1).then((value) => {x = value}); // type warning
}

https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520ADVANCED_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250Aasync%2520function%2520foo()%2520%257B%250A%2520%2520let%2520%252F*%2520null%2520%252F%2520x%2520%253D%2520await%2520Promise.resolve(1)%253B%250A%2520%2520Promise.resolve(1).then((value)%2520%253D%253E%2520%257Bx%2520%253D%2520value%257D)%253B%250A%257D

[ikabirov]

/** @return {string} */
async function foo() {
  let /** null */ x = await Promise.resolve(1);
  Promise.resolve(1).then((value) => {x = value});

  return 1; 
}
// found   : Promise<?>
// required: string

found value should be Promise<number>

[jplaisted]

I think there's a bit of a philosophical debate here if you should annotate async functions as returning Promise<T> or just T. But in either case yes it would be nice if T could be checked correctly.

[ikabirov]

No, it's bug. await always returns ? (T expected), async function always returns Promise<?> (Promise<T> expected).
Seems that context is loosed

[brad4d]

We're actively working to improve type checking for async functions this quarter.
I expect this to get fixed as part of that work.

[ikabirov]

Any news on this?

[brad4d]

Current status of the work I mentioned is that we're close to having ES6 class transpilation happen after type checking. Most of what's left is fixing Google internal code containing type-related errors previously hidden by the transpilation.

After that the next blocker is moving destructuring transpilation.
@lauraharker has been very active in making the changes needed to make that happen.

After that moving async function transpilation will be relatively easy, possibly a single commit, because theoretically all the work needed other than moving the other transpilations it depends on is already done.

I expect it all to be done by the end of this quarter.

[ikabirov]

fixed in v20181125 ?

[lauraharker]

Yes, this is fixed in v20181125. Specifically by 4b6d65e7b2ee827e3f7f3ee62731ebda537958f5