-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
@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? |
I'd be more than happy to tackle this one! |
Async functions are built on top of generator functions, and the core of the problem is going to be in how they are transpiled. 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. |
Snip, was thinking this was an issue with yields as well, but they work differently. Forgot yield's value is the argument to next(). |
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. |
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: 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. |
Just pulled the trigger today on a change that moves async function transpilation after type checking. 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. |
See #2540 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=222265244
There is no type checking on the implicit results of an await expression. To me this seems different than issue #2191.
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.
The text was updated successfully, but these errors were encountered: