Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No type checking on await expression values #2540

Closed
jplaisted opened this issue Jun 19, 2017 · 7 comments
Closed

No type checking on await expression values #2540

jplaisted opened this issue Jun 19, 2017 · 7 comments
Assignees

Comments

@jplaisted
Copy link
Contributor

There is no type checking on the implicit results of an await expression. To me this seems different than issue #2191.

/** @param {string} arg */
function strFn(arg) {}

async function asyncFn() {
  const v = await Promise.resolve(5);
  strFn(v); // Ignored
}

function callbackFn() {
  Promise.resolve(5).then(strFn); // WARNING
}

Debug link

I assume type checking is done post-transpilation in which case there needs to be casts within each generator switch statement. There is no type safety on the argument to the generator is the fundamental issue here.

Debug link to the above example with casting.

@shicks
Copy link
Member

shicks commented Jun 19, 2017

@jplaisted Would you be up for digging through the async rewrite pass to see if you can insert those cast nodes where appropriate?

@brad4d Can you point John in the right direction?

@jplaisted
Copy link
Contributor Author

I'd be more than happy to tackle this one!

@brad4d
Copy link
Contributor

brad4d commented Jun 20, 2017

Async functions are built on top of generator functions, and the core of the problem is going to be in how they are transpiled.

https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/Es6RewriteGenerators.java

I am aware of a handful of bugs with this pass, most of them related to type information. I want to spend some time really figuring out how it works and where it needs fixing, but I've been busy with higher priority things.

@jplaisted if you'd like to dig into that pass and improve the typing with a pull request or two, I will be absolutely delighted to shepherd them in.

@brad4d brad4d self-assigned this Jun 20, 2017
@jplaisted jplaisted changed the title No type checking on await expression values No type checking on yield and await expression values Jun 21, 2017
@jplaisted
Copy link
Contributor Author

jplaisted commented Jun 21, 2017

Snip, was thinking this was an issue with yields as well, but they work differently. Forgot yield's value is the argument to next().

@jplaisted jplaisted changed the title No type checking on yield and await expression values No type checking on await expression values Jun 21, 2017
@jplaisted
Copy link
Contributor Author

We discussed this and it isn't a trivial task in the rewrite async / generators since type checking is done post transpilation. Difficult to get the type of the expression both pre- and post- transpiltation as a result.

@chrismiddleton
Copy link
Contributor

I'm not sure if this is the same issue, but when I test with the current compiler, there is no type checking on await expressions. Example here:

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%250A%252F**%250A%2520*%2520%2540return%2520%257BPromise%253CString%253E!%257D%250A**%252F%250Aasync%2520function%2520hello()%2520%257B%250A%2520%2520return%2520Promise.resolve(2)%253B%250A%257D%250A%250Aasync%2520function%2520run%2520()%2520%257B%250A%2520%2520var%2520result%2520%253D%2520await%2520hello()%253B%250A%2520%2520alert(result.slice(0%252C%25205))%253B%250A%257D%250A%250Aasync%2520function%2520run2%2520()%2520%257B%250A%2520%2520%252F**%2520%2540type%2520%257Bnumber%257D%2520*%252F%250A%2520%2520var%2520result2%2520%253D%2520await%2520hello()%253B%250A%2520%2520alert(result2.slice(0%252C%25205))%253B%250A%257D%250A%250Arun()%253B%250Arun2()%253B%250A

I think it would be a good idea to put a big warning about the lack of type-checking for async/await, since this feature has been missing for so long so as to qualify as a bug that everyone should know about.

I was on a project that used async/await and this lack of type checking was not obvious to us, and we had a few cases where bugs that made it to the end-user were caused by this lack of type checking.

I'd almost rather have not used async/await at all or at least known that the type-checking was absent, because you write code differently when you think the compiler is checking for you. When you refactor code and you fix all the type errors, you think that you've fixed it, when in reality, you haven't, due to this lack of type checking await. Whereas if I knew that it wasn't type-checking from the start, I either wouldn't have used async/await, or I would have written the code / done the refactors differently to ensure there weren't problems.

@brad4d
Copy link
Contributor

brad4d commented Nov 20, 2018

Just pulled the trigger today on a change that moves async function transpilation after type checking.
The change will be pushed to GitHub tomorrow.

With this change type checking within async functions and on await statements should be just the same as in ordinary functions.

So, I'm closing this issue.
Please open a new issue for specific type checking problems if you find they are still happening after that change is pushed.

@brad4d brad4d closed this as completed Nov 20, 2018
lauraharker pushed a commit that referenced this issue Nov 21, 2018
See #2540

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222265244
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants