-
Notifications
You must be signed in to change notification settings - Fork 5.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
Support top-level await #471
Comments
If we wanted this to work while we are waiting on TC39/TypeScript, we would have to do a bit of hackery. When emitting a module with TLA, we would have to specifically ignore the diagnostic error related to that. TypeScript always emits, it is us who then chooses to throw. I might be a good idea to actually log a warning, since when TLA arrives, it could be a different behaviour to what we would have. Then we would have to modify the AMD factory function to be |
The drawback, like the module specifiers ending in |
https://github.com/tc39/proposal-top-level-await#optional-constraint-top-level-await-can-only-be-used-in-modules-without-exports |
TC39 start promoting it. |
Well, one member of TC39 is trying to get it moving again. I am not sure we can really add anything to it. The biggest challenge is that they need to address the functional challenge that top-level await and how modules are evaluated and as Ry mentioned above, the optional restriction would make it a lot easier, but this is really needs the implementors to figure out how to do it, versus adding another voice to the mix. |
Top level await has gone Stage 3. That means that the TypeScript team should be willing to implement it now. |
A V8 issue has been created for this https://bugs.chromium.org/p/v8/issues/detail?id=9344 |
The TypeScript team are indicating that it will be challenging to downemit and are considering not allowing a downemit. That is find from our perspective, but that "problem" continues to delay them addressing the issue. |
https://chromium.googlesource.com/v8/v8.git/+/591d1c9de4b3f2e4159c01d57f2c1e6e37d7cb41 TLA support has landed in V8 |
TLA is scheduled for TS 3.7 as well (early-November): microsoft/TypeScript#33352 |
Reverted v8/v8@93a29bd |
Relanded v8/v8@798cb90 |
Parsing support has landed https://chromium.googlesource.com/v8/v8.git/+/0ceee9ad28c21bc4971fb237cf87eb742fc787b8 |
Deno v0.19 has integrated the changes from V8 and has a test demonstrating TLA. However this is JS only support. We still need TS to not barf on TLA syntax. Therefore I'm leaving this issue open until we have a corresponding |
That should be doable without ignoring error codes with TS 3.7 on Nov 5th. |
@kitsonk In this latest TS 3.7 announcement, there is no indication that there will be any support for TLA by Nov 5th. |
That is the beta, and the announcement is what is in the beta. The iteration plan mentioned above still lists it. I am sure Ry and I will chat to the team about it next week at TSConf. |
In case people are following this, here's v8 issues for top-level for-await (not merged yet): https://bugs.chromium.org/p/v8/issues/detail?id=9817 |
Also, I had a chat with Daniel R, PM on TypeScript team, and TLA won't make TypeScript 3.7. It simply causes us to ignore the error message in Deno and will show it as invalid in editors, though it will run fine under Deno. |
guess I was right then.. |
Yes, not enough time in the team. I think some of the other features took longer than they anticipated. |
Actually, re-reading those commits above I think top-level for-await is in recent V8 versions. IIRC this means we can support it in ts easily once we upgrade V8. |
I see that TypeScript now has first release with Top Level Await at 3.8. Does this help the progress of TLA in Deno? |
Deno has TLA. You are commenting on a closed issue. |
Thanks. |
This example seems to not work : function add(a: any,b: any,c: any): any{
if(a+b>10){
return c("My error",a+b);
}else{
return c(null, a+b);
}
}
try{
let t = await (async()=>{
return add(4,5,(e: any, r: any)=>{
if(e) throw e;
return r;
});
})();
console.log(t);
}catch(e){
console.log("Yes! caught error from call back: ", e);
} Gives me this error: |
@anuragvohraec this is a TypeScript problem, and the error is a mis-leading... because you don't have any imports or exports in the module, TypeScript is treating this like a script instead of a module. This is causing the parsing in the try block to be a bit off, and instead of telling you that the module isn't a module error, it is giving you this strange error. To work around the issue just add the following at the start or the end of the module: export {}; |
still same error : export {};
function add(a: any,b: any,c: any): any{
if(a+b>10){
return c("My error",a+b);
}else{
return c(null, a+b);
}
}
try{
let t = await (async()=>{
return add(4,5,(e: any, r: any)=>{
if(e) throw e;
return r;
});
})();
console.log(t);
}catch(e){
console.log("Yes! caught error from call back: ", e);
} |
@anuragvohraec - Pardon my N00b question, but when would you use the From my understanding, all functions in |
No, not all functions in are implicitly await foo() // valid here
function test1() {
await foo() // invalid here
}
async function test2() {
await foo() // valid here
} More info on top level await: https://v8.dev/features/top-level-await |
@lucacasonato - Thanks, that makes sense. I found a good example explaining the use of @anuragvohraec - Here is a tweak to your code that works for me:
|
@anuragvohraec it is a TypeScript lexing issue. Upstream bug filed: microsoft/TypeScript#38483. |
The real world example for this will be to convert a call back based asynchronous function be converted to async await based without using a Promise API. If you see my example: function add(a: any,b: any,c: any): any{
if(a+b>10){
return c("My error",a+b);
}else{
return c(null, a+b);
}
}
try{
let t = await (async()=>{
return add(4,5,(e: any, r: any)=>{
if(e) throw e;
return r;
});
})();
console.log(t);
}catch(e){
console.log("Yes! caught error from call back: ", e);
}
|
The code I have shared do not commits any mistake mentioned in your code samples. |
@anuragvohraec I don't think @lucacasonato was complaining about your code, but was just trying to inform @JavaScriptDude on how async/await works. Your code is valid JavaScript, and should be valid TypeScript but TypeScript has a bug. |
is TLA supported in deno REPL? I cant seem to get the following to work.
$ deno
> console.log(await Promise.resolve('Success')) It just seems to await indefinitely without outputting anything or allowing me to input any further commands. |
…nd#471) Due to V8's PKU feature, only the thread that initialized the V8 platform or those spawned from it can access the isolates; other threads will get a segmentation fault. Since each test runs in its thread, they crash on newer CPUs that support PKU. This issue has two possible solutions: 1. Initialize the platform once in the main thread. 2. Turn off the PKU feature during testing. This issue was already encountered for the `deno test` command, which was resolved by initializing the platform in the main thread (denoland#20495). In the case of rust tests, the same solution cannot be used, as the default test runner does not allow running code on the main thread before any test runs. My proposed solution is to add a feature flag to deno_core, which, when enabled, uses the unprotected platform. An alternative solution could be to call `deno_core::JsRuntime::init_platform` at the beginning of each test. This PR will also be a step towards fixing denoland#21439
microsoft/TypeScript#25988
https://github.com/tc39/proposal-top-level-await
https://bugs.chromium.org/p/v8/issues/detail?id=9344
The text was updated successfully, but these errors were encountered: