| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…mer-es6-generators
…mer-es6-generators
…er-es6-generators
|
CC: Vladimir Matveev (@vladima), Mohamed Hegazy (@mhegazy), Yui (@yuit), Nathan Shively-Sanders (@sandersn), Wesley Wigham (@weswigham), Daniel Rosenwasser (@DanielRosenwasser) |
Sorry, something went wrong.
| } | ||
|
|
||
| export function createTempVariable(recordTempVariable: (node: Identifier) => void, location?: TextRange): Identifier { | ||
| export function createTempVariable(recordTempVariable: ((node: Identifier) => void) | undefined, location?: TextRange): Identifier { |
There was a problem hiding this comment.
Why not recordTempVariable?: (node: Identifier) => void?
Sorry, something went wrong.
There was a problem hiding this comment.
To catch mistakes. Its acceptable to not record the temp variable, but you almost always want to. The only cases where we don't are when we're creating a temp parameter, or we are going to add the temp variable name to a VariableDeclarationList ourselves.
Sorry, something went wrong.
|
We need to handle directive prologues ("use strict";) when transforming async functions - I looked at the output of the tests/cases/conformance/async/es6/await[Binary,Call]Expression_es6 tests on this branch (which conveniently always have a string as their first statement!) and noticed that we move prologues into the generator function we synthesize - this is likely incorrect (even if it's our current behavior) if the consumer is using custom prologues (if they were just using "use strict" they may never notice). In any case, generators, also, need to special case retaining prologues as the first statement in the original outer function declaration (though, maybe not applicable right now since generators only arise as a consequence of async functions). Also, would it be possible to just see the results of those same conformance tests running vs es5/es3? I know you added a bunch of new tests, but simply replicating the tests/cases/conformance/async/es6 directory for es5 and maybe es3 would be pertinent with this change. (And allow useful comparisons) #Resolved |
Sorry, something went wrong.
|
I don't think there's any issues, but I couldn't find a test to confirm - I don't see any tests (existing or otherwise) covering constructs such as class extends (await whatever) (which should be valid within an async function). Given we check our emit for await pretty much everywhere else, we should probably add tests in an extends clause. |
Sorry, something went wrong.
| define(["require", "exports"], function (require, exports) { | ||
| "use strict"; | ||
| return (_a = {}, _a["hi"] = "there", _a); | ||
| return _a = {}, _a["hi"] = "there", _a; |
There was a problem hiding this comment.
Is the removal of the parenthesis in this test output and the one below intentional? #Resolved
Sorry, something went wrong.
There was a problem hiding this comment.
Yes. The node factories will automatically add parenthesis if they are needed. As a result, many places where we explicitly added parentheses now instead leverage this behavior. In this instance, the createReturn factory does not need to parenthesize, so they are not added.
Sorry, something went wrong.
…ity to treat some statements as if they were prologue directives.
…urning global promise, pass this to __generator
…referencing 'arguments' in a generator.
|
Yui (@yuit), Wesley Wigham (@weswigham): Please take another look following the recent commits. |
Sorry, something went wrong.
|
Does this PR being merged mean we can use async/await now with transpilation to < ES6? |
Sorry, something went wrong.
|
It's merged with the transforms branch, not master. It won't ship until transforms merges into master. |
Sorry, something went wrong.
|
Anything new on this one? When will it be available in typescript@next? |
Sorry, something went wrong.
|
should start showing up in typescript@next next week. |
Sorry, something went wrong.
|
those using tslib and noEmitHelpers must install tslib from github as the npm package is not updated yet (and thus does not contain __generator). |
Sorry, something went wrong.
|
I got excited enough by @mghegazy's comment earlier that I went ahead and installed typescript@next on my project to start refactoring some of my more labyrinthine promise usage into async/await. And did not bother to check whether transforms had actually been merged into master 😄 And I was like, whoa, this already works when targeting ES5! But then I realized the output is still using ES6 generators, which just happen to work in Chrome and the iOS 10 webview I was testing in 🤐 |
Sorry, something went wrong.
jkobylec i do not think this is accurate. Emitting async functions for ES3/ES5 is supported in typescript@next. here is a demonstration. c:\test>tsc --v
Version 2.1.0-dev.20161014
c:\test>type a.ts
async function test() {
await bar();
}
c:\test>tsc --target ES5 --lib es5,es2015.promise a.ts
a.ts(2,11): error TS2304: Cannot find name 'bar'.
c:\test>type a.js
var __awaiter =...
var __generator = ...
function test() {
return __awaiter(this, void 0, void 0, function () {
return __generator(this, function (_a) {
switch (_a.label) {
case 0: return [4 /*yield*/, bar()];
case 1:
_a.sent();
return [2 /*return*/];
}
});
});
}Also i would recommend creating a new issue instead of commenting on a closed PR. thanks. |
Sorry, something went wrong.
|
My assumption was that the incorporation into master was still in progress
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This change adds support for transforming a subset of generator function features to a down-level representation to support async functions when targeting ES5 or ES3.