profile
viewpoint
yulia codehag @mozilla http://hag.codes FKA @ioctaptceb Twitter remains; image by Tristan Elwell

mozilla-spidermonkey/jsparagus 180

Parser generators

mozilla/pretty-fast 50

Pretty Fast is a source-map-generating JavaScript pretty printer, used by the Firefox Developer Tools debugger.

codehag/js-better-errors 33

Let's discuss making better errors for JavaScript

mozilla-spidermonkey/rust-frontend 18

*Experimental* work on potentially rewriting the spidermonkey frontend. Not guaranteed to be merged.

bmeck/proposal-debugger-operands 13

Adding an optional operand to the DebuggerStatement production of JS

codehag/TC39-news 4

News from the depths

codehag/TC39-Panel-Prep 3

Preparation for JSConfEU 2017 TC39 Panel

codehag/debugger.html 1

The Firefox debugger that works anywhere :boom:

push eventcodehag/proposal-top-level-await

codehag

commit sha 39474cf124158756c7822eda444c7c82ae2ffd31

update spec.html to current spec -- part 1

view details

codehag

commit sha 38735996f8eb7f8f482eca4ad0a11f4a44e02d40

move source module record description to cyclical module record and update accordingly

view details

codehag

commit sha a95c1376bc21a42c05d89e13bdf18bf2d3c98d0d

TopLevelModuleEvaluationJob no longer exists, we need to find the right place to move these instructions to

view details

push time in 5 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>Example Source Text Module Record Graphs</h1>         </tbody>       </table>     </emu-table>-   </emu-clause>--  <emu-clause id="sec-toplevelmoduleevaluationjob" aoid="TopLevelModuleEvaluationJob">

This section is moved to the bottom, unchanged.

codehag

comment created time in 5 hours

push eventcodehag/proposal-top-level-await

codehag

commit sha 0dac0e0db172933868d017d7cd1522aebecddf75

move source module record description to cyclical module record and update accordingly

view details

codehag

commit sha 19d2a2ad5faaa9a4b26e394457d3a0f383905151

TopLevelModuleEvaluationJob no longer exists, we need to find the right place to move these instructions to

view details

push time in 5 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>InnerModuleEvaluation( _module_, _stack_, _index_ )</h1>     <emu-clause id="sec-execute-async-module" aoid="ExecuteAsyncModule">       <h1><ins>ExecuteAsyncModule ( _module_ )</ins></h1>       <emu-alg>-        1. Assert: _module_.[[Status]] is `"evaluating"` or `"evaluated"`.-        1. Assert: _module_.[[Async]] is *true*.-        1. Set _module_.[[AsyncEvaluating]] to *true*.-        1. Let _capability_ be ! NewPromiseCapability(%Promise%).-        1. Let _stepsFulfilled_ be the steps of a CallAsyncModuleFulfilled function as specified below.-        1. Let _onFulfilled_ be CreateBuiltinFunction(_stepsFulfilled_, &laquo; [[Module]] &raquo;).-        1. Set _onFulfilled_.[[Module]] to _module_.-        1. Let _stepsRejected_ be the steps of a CallAsyncModuleRejected function as specified below.-        1. Let _onRejected_ be CreateBuiltinFunction(_stepsRejected_, &laquo; [[Module]] &raquo;).-        1. Set _onRejected_.[[Module]] to _module_.-        1. Perform ! PerformPromiseThen(_capability_.[[Promise]], _onFulfilled_, _onRejected_).-        1. Perform ! _module_.ExecuteModule(_capability_).-        1. Return.+        1. <ins>Assert: _module_.[[Status]] is `"evaluating"` or `"evaluated"`.</ins>+        1. <ins>Assert: _module_.[[Async]] is *true*.</ins>+        1. <ins>Set _module_.[[AsyncEvaluating]] to *true*.</ins>+        1. <ins>Let _capability_ be ! NewPromiseCapability(%Promise%).</ins>+        1. <ins>Let _stepsFulfilled_ be the steps of a CallAsyncModuleFulfilled function as specified below.</ins>+        1. <ins>Let _onFulfilled_ be CreateBuiltinFunction(_stepsFulfilled_, &laquo; [[Module]] &raquo;).</ins>+        1. <ins>Set _onFulfilled_.[[Module]] to _module_.</ins>+        1. <ins>Let _stepsRejected_ be the steps of a CallAsyncModuleRejected function as specified below.</ins>+        1. <ins>Let _onRejected_ be CreateBuiltinFunction(_stepsRejected_, &laquo; [[Module]] &raquo;).</ins>+        1. <ins>Set _onRejected_.[[Module]] to _module_.</ins>+        1. <ins>Perform ! PerformPromiseThen(_capability_.[[Promise]], _onFulfilled_, _onRejected_).</ins>+        1. <ins>Perform ! _module_.ExecuteModule(_capability_).</ins>+        1. <ins>Return.</ins>       </emu-alg> -      <p>A CallAsyncModuleFulfilled function is an anonymous built-in function with a [[Module]] internal slot. When a CallAsyncModuleFulfilled function is called that expects no arguments it performs the following steps:</p>+      <p><ins>A CallAsyncModuleFulfilled function is an anonymous built-in function with a+        [[Module]] internal slot. When a CallAsyncModuleFulfilled function is called that expects no+        arguments it performs the following steps:</ins></p>       <emu-alg>-        1. Let _f_ be the active function object.-        1. Let _module_ be _f_.[[Module]].-        1. Perform ! AsyncModuleExecutionFulfilled(_module_).-        1. Return.+        1. <ins>Let _f_ be the active function object.</ins>+        1. <ins>Let _module_ be _f_.[[Module]].</ins>+        1. <ins>Perform ! AsyncModuleExecutionFulfilled(_module_).</ins>+        1. <ins>Return.</ins>       </emu-alg> -      <p>A CallAsyncModuleRejected function is an anonymous built-in function with a [[Module]] internal slot. When a CallAsyncModuleRejected function is called with argument _error_ it performs the following steps:</p>+      <p><ins>A CallAsyncModuleRejected function is an anonymous built-in function with a [[Module]] internal slot. When a CallAsyncModuleRejected function is called with argument _error_ it performs the following steps:</ins></p>       <emu-alg>-        1. Let _f_ be the active function object.-        1. Let _module_ be _f_.[[Module]].-        1. Perform ! AsyncModuleExecutionRejected(_module_, _error_).-        1. Return.+        1. <ins>Let _f_ be the active function object.</ins>+        1. <ins>Let _module_ be _f_.[[Module]].</ins>+        1. <ins>Perform ! AsyncModuleExecutionRejected(_module_, _error_).</ins>+        1. <ins>Return.</ins>       </emu-alg>     </emu-clause>      <emu-clause id="sec-getasynccycleroot" aoid="GetAsyncCycleRoot">       <h1><ins>GetAsyncCycleRoot ( _module_ )</ins></h1>       <emu-alg>-        1. Assert: _module_.[[Status]] is `"evaluated"`.-        1. If _module_.[[AsyncParentModules]] is an empty List, return _module_.-        1. Repeat, while _module_.[[DFSIndex]] is greater than _module_.[[DFSAncestorIndex]],-          1. Assert: _module_.[[AsyncParentModules]] is a non-empty List.-          1. Let _nextCycleModule_ be the first element of _module_.[[AsyncParentModules]].-          1. Assert: _nextCycleModule_.[[DFSAncestorIndex]] is less than or equal to _module_.[[DFSAncestorIndex]].-          1. Set _module_ to _nextCycleModule_.-        1. Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].-        1. Return _module_.+        1. <ins>Assert: _module_.[[Status]] is `"evaluated"`.</ins>+        1. <ins>If _module_.[[AsyncParentModules]] is an empty List, return _module_.</ins>+        1. <ins>Repeat, while _module_.[[DFSIndex]] is greater than _module_.[[DFSAncestorIndex]],</ins>+          1. <ins>Assert: _module_.[[AsyncParentModules]] is a non-empty List.</ins>+          1. <ins>Let _nextCycleModule_ be the first element of _module_.[[AsyncParentModules]].</ins>+          1. <ins>Assert: _nextCycleModule_.[[DFSAncestorIndex]] is less than or equal to _module_.[[DFSAncestorIndex]].</ins>+          1. <ins>Set _module_ to _nextCycleModule_.</ins>+        1. <ins>Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].</ins>+        1. <ins>Return _module_.</ins>       </emu-alg>     </emu-clause>      <emu-clause id="sec-asyncmodulexecutionfulfilled" aoid="AsyncModuleExecutionFulfilled">       <h1><ins>AsyncModuleExecutionFulfilled ( _module_ )</ins></h1>       <emu-alg>-        1. Assert: _module_.[[Status]] is `"evaluated"`.-        1. If _module_.[[AsyncEvaluating]] is *false*,-          1. Assert: _module_.[[EvaluationError]] is not *undefined*.-          1. Return *undefined*.-        1. Assert: _module_.[[EvaluationError]] is *undefined*.-        1. Set _module_.[[AsyncEvaluating]] to *false*.-        1. For each Module _m_ of _module_.[[AsyncParentModules]], do-          1. If _module_.[[DFSIndex]] is not equal to _module_.[[DFSAncestorIndex]], then-            1. Assert: _m_.[[DFSAncestorIndex]] is less than or equal to _module_.[[DFSAncestorIndex]].-          1. Decrement _m_.[[PendingAsyncDependencies]] by 1.-          1. If _m_.[[PendingAsyncDependencies]] is 0 and _m_.[[EvaluationError]] is *undefined*, then-            1. Assert: _m_.[[AsyncEvaluating]] is *true*.-            1. Let _cycleRoot_ be ! GetAsyncCycleRoot(_m_).-            1. If _cycleRoot_.[[EvaluationError]] is not *undefined*, return *undefined*.-            1. If _m_.[[Async]] is *true*, then-              1. Perform ! ExecuteAsyncModule(_m_).-            1. Otherwise,-              1. Let _result_ be _m_.ExecuteModule().-              1. If _result_ is a normal completion,-                1. Perform ! AsyncModuleExecutionFulfilled(_m_).-              1. Otherwise,-                1. Perform ! AsyncModuleExecutionRejected(_m_, _result_.[[Value]]).-        1. If _module_.[[TopLevelCapability]] is not *undefined*, then-          1. Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].-          1. Perform ! Call(_module_.[[TopLevelCapability]].[[Resolve]], *undefined*, &laquo;*undefined*&raquo;).-        1. Return *undefined*.+        1. <ins>Assert: _module_.[[Status]] is `"evaluated"`.</ins>+        1. <ins>If _module_.[[AsyncEvaluating]] is *false*,</ins>+          1. <ins>Assert: _module_.[[EvaluationError]] is not *undefined*.</ins>+          1. <ins>Return *undefined*.</ins>+        1. <ins>Assert: _module_.[[EvaluationError]] is *undefined*.</ins>+        1. <ins>Set _module_.[[AsyncEvaluating]] to *false*.</ins>+        1. <ins>For each Module _m_ of _module_.[[AsyncParentModules]], do</ins>+          1. <ins>If _module_.[[DFSIndex]] is not equal to _module_.[[DFSAncestorIndex]], then</ins>+            1. <ins>Assert: _m_.[[DFSAncestorIndex]] is less than or equal to _module_.[[DFSAncestorIndex]].</ins>+          1. <ins>Decrement _m_.[[PendingAsyncDependencies]] by 1.</ins>+          1. <ins>If _m_.[[PendingAsyncDependencies]] is 0 and _m_.[[EvaluationError]] is *undefined*, then</ins>+            1. <ins>Assert: _m_.[[AsyncEvaluating]] is *true*.</ins>+            1. <ins>Let _cycleRoot_ be ! GetAsyncCycleRoot(_m_).</ins>+            1. <ins>If _cycleRoot_.[[EvaluationError]] is not *undefined*, return *undefined*.</ins>+            1. <ins>If _m_.[[Async]] is *true*, then</ins>+              1. <ins>Perform ! ExecuteAsyncModule(_m_).</ins>+            1. <ins>Otherwise,</ins>+              1. <ins>Let _result_ be _m_.ExecuteModule().</ins>+              1. <ins>If _result_ is a normal completion,</ins>+                1. <ins>Perform ! AsyncModuleExecutionFulfilled(_m_).</ins>+              1. <ins>Otherwise,</ins>+                1. <ins>Perform ! AsyncModuleExecutionRejected(_m_, _result_.[[Value]]).</ins>+        1. <ins>If _module_.[[TopLevelCapability]] is not *undefined*, then</ins>+          1. <ins>Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].</ins>+          1. <ins>Perform ! Call(_module_.[[TopLevelCapability]].[[Resolve]], *undefined*, &laquo;*undefined*&raquo;).</ins>+        1. <ins>Return *undefined*.</ins>       </emu-alg>     </emu-clause>      <emu-clause id="sec-AsyncModuleExecutionRejected" aoid="AsyncModuleExecutionRejected">       <h1><ins>AsyncModuleExecutionRejected ( _module_, _error_ )</ins></h1>       <emu-alg>-        1. Assert: _module_.[[Status]] is `"evaluated"`.-        1. If _module_.[[AsyncEvaluating]] is *false*,-          1. Assert: _module_.[[EvaluationError]] is not *undefined*.-          1. Return *undefined*.-        1. Assert: _module_.[[EvaluationError]] is *undefined*.-        1. Set _module_.[[EvaluationError]] to ThrowCompletion(_error_).-        1. Set _module_.[[AsyncEvaluating]] to *false*.-        1. For each Module _m_ of _module_.[[AsyncParentModules]], do-          1. If _module_.[[DFSIndex]] is not equal to _module_.[[DFSAncestorIndex]], then-            1. Assert: _m_.[[DFSAncestorIndex]] is equal to _module_.[[DFSAncestorIndex]].-          1. Perform ! AsyncModuleExecutionRejected(_m_, _error_).-        1. If _module_.[[TopLevelCapability]] is not *undefined*, then-          1. Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].-          1. Perform ! Call(_module_.[[TopLevelCapability]].[[Reject]], *undefined*, &laquo;_error_&raquo;).-        1. Return *undefined*.+        1. <ins>Assert: _module_.[[Status]] is `"evaluated"`.</ins>+        1. <ins>If _module_.[[AsyncEvaluating]] is *false*,</ins>+          1. <ins>Assert: _module_.[[EvaluationError]] is not *undefined*.</ins>+          1. <ins>Return *undefined*.</ins>+        1. <ins>Assert: _module_.[[EvaluationError]] is *undefined*.</ins>+        1. <ins>Set _module_.[[EvaluationError]] to ThrowCompletion(_error_).</ins>+        1. <ins>Set _module_.[[AsyncEvaluating]] to *false*.</ins>+        1. <ins>For each Module _m_ of _module_.[[AsyncParentModules]], do</ins>+          1. <ins>If _module_.[[DFSIndex]] is not equal to _module_.[[DFSAncestorIndex]], then</ins>+            1. <ins>Assert: _m_.[[DFSAncestorIndex]] is equal to _module_.[[DFSAncestorIndex]].</ins>+          1. <ins>Perform ! AsyncModuleExecutionRejected(_m_, _error_).</ins>+        1. <ins>If _module_.[[TopLevelCapability]] is not *undefined*, then</ins>+          1. <ins>Assert: _module_.[[DFSIndex]] is equal to _module_.[[DFSAncestorIndex]].</ins>+          1. <ins>Perform ! Call(_module_.[[TopLevelCapability]].[[Reject]], *undefined*, &laquo;_error_&raquo;).</ins>+        1. <ins>Return *undefined*.</ins>       </emu-alg>     </emu-clause>   </emu-clause>-</emu-clause> -<emu-clause id="sec-source-text-module-records">-    <h1>Source Text Module Records</h1>--  <emu-clause id="sec-parsemodule" aoid="ParseModule">-    <h1>ParseModule ( _sourceText_, _realm_, _hostDefined_ )</h1>

Done

codehag

comment created time in 5 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>Evaluate ( ) Concrete Method</h1>       1. Let _result_ be InnerModuleEvaluation(_module_, _stack_, 0).       1. If _result_ is an abrupt completion, then         1. For each Cyclic Module Record _m_ in _stack_, do-          1. Assert: _m_.[[Status]] is `"evaluating"`.-          1. Set _m_.[[Status]] to `"evaluated"`.+          1. Assert: _m_.[[Status]] is ~evaluating~.+          1. Set _m_.[[Status]] to ~evaluated~.           1. Set _m_.[[EvaluationError]] to _result_.-        1. Assert: _module_.[[Status]] is `"evaluated"` and _module_.[[EvaluationError]] is _result_.+        1. Assert: _module_.[[Status]] is ~evaluated~ and _module_.[[EvaluationError]] is _result_.         1. <del>Return _result_.</del>         1. <ins>Perform ! Call(_capability_.[[Reject]], *undefined*, &laquo;_result_.[[Value]]&raquo;).</ins>       1. <ins>Otherwise,</ins>-        1. Assert: _module_.[[Status]] is `"evaluated"` and _module_.[[EvaluationError]] is *undefined*.+      <ins>  </ins>1. Assert: _module_.[[Status]] is ~evaluated~ and _module_.[[EvaluationError]] is *undefined*.         1. <ins>If _module_.[[AsyncEvaluating]] is *false*, then</ins>-          1. <ins>Perform ! Call(_capability_.[[Resolve]], *undefined*, &laquo;*undefined*&raquo;).</ins>-        1. Assert: _stack_ is empty.+        1. <ins>Perform ! Call(_capability_.[[Resolve]], *undefined*, &laquo;*undefined*&raquo;).</ins>+      <ins>  </ins>1. Assert: _stack_ is empty.       1. Return <del>*undefined*</del><ins>_capability_.[[Promise]]</ins>.     </emu-alg>      <emu-clause id="sec-innermoduleevaluation" aoid="InnerModuleEvaluation">-      <h1>InnerModuleEvaluation( _module_, _stack_, _index_ )</h1>--      <p>The InnerModuleEvaluation abstract operation is used by Evaluate to perform the actual evaluation process for the Cyclic Module Record _module_, as well as recursively on all other modules in the dependency graph. The _stack_ and _index_ parameters, as well as _module_'s [[DFSIndex]] and [[DFSAncestoreIndex]] fields, are used the same way as in InnerModuleLinking.</p>+      <h1>InnerModuleEvaluation ( _module_, _stack_, _index_ )</h1>+      <p>The abstract operation InnerModuleEvaluation takes arguments _module_ (a Source Text Module Record), _stack_, and _index_. It is used by Evaluate to perform the actual evaluation process for _module_, as well as recursively on all other modules in the dependency graph. The _stack_ and _index_ parameters, as well as _module_'s [[DFSIndex]] and [[DFSAncestorIndex]] fields, are used the same way as in InnerModuleLinking. It performs the following steps when called:</p>

Should we do the change there first?

codehag

comment created time in 5 hours

push eventcodehag/proposal-top-level-await

codehag

commit sha 7d0d1939d26033b8b9ec2a6333873489ee162d02

update spec.html to current spec -- part 1

view details

codehag

commit sha 725abea1631b0c56d8317f44304e56e820ac3a95

move source module record description to cyclical module record and update accordingly

view details

codehag

commit sha ec38e4303f477fc92aeb4117dac905d86b389bdb

TopLevelModuleEvaluationJob no longer exists, we need to find the right place to move these instructions to

view details

push time in 5 hours

push eventcodehag/proposal-top-level-await

codehag

commit sha 0f04e8c8a30cc099b19c9c4f746bcadc4310db93

update spec.html to current spec -- part 1

view details

codehag

commit sha f198753145cdd6a25191081b4fb52d950dcf74a1

move source module record description to cyclical module record and update accordingly

view details

codehag

commit sha 8c87aaf7850d0f7b12035febd00d7e5f18af5049

TopLevelModuleEvaluationJob no longer exists, we need to find the right place to move these instructions to

view details

push time in 6 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>Evaluate ( ) Concrete Method</h1>       1. Let _result_ be InnerModuleEvaluation(_module_, _stack_, 0).       1. If _result_ is an abrupt completion, then         1. For each Cyclic Module Record _m_ in _stack_, do-          1. Assert: _m_.[[Status]] is `"evaluating"`.-          1. Set _m_.[[Status]] to `"evaluated"`.+          1. Assert: _m_.[[Status]] is ~evaluating~.+          1. Set _m_.[[Status]] to ~evaluated~.           1. Set _m_.[[EvaluationError]] to _result_.-        1. Assert: _module_.[[Status]] is `"evaluated"` and _module_.[[EvaluationError]] is _result_.+        1. Assert: _module_.[[Status]] is ~evaluated~ and _module_.[[EvaluationError]] is _result_.         1. <del>Return _result_.</del>         1. <ins>Perform ! Call(_capability_.[[Reject]], *undefined*, &laquo;_result_.[[Value]]&raquo;).</ins>       1. <ins>Otherwise,</ins>-        1. Assert: _module_.[[Status]] is `"evaluated"` and _module_.[[EvaluationError]] is *undefined*.+      <ins>  </ins>1. Assert: _module_.[[Status]] is ~evaluated~ and _module_.[[EvaluationError]] is *undefined*.

Hm, doesn't break, but doesn't have the intended effect either.

codehag

comment created time in 6 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>Example Source Text Module Record Graphs</h1>       <img alt="A module graph in which module A depends on a missing (unresolvable) module, represented by ???" width="121" height="121" src="img/module-graph-missing.svg">     </emu-figure> -    <p>In this scenario, module _A_ declares a dependency on some other module, but no Module Record exists for that module, i.e. HostResolveImportedModule throws an exception when asked for it. This could occur for a variety of reasons, such as the corresponding resource not existing, or the resource existing but ParseModule throwing an exception when trying to parse the resulting source text. Hosts can choose to expose the cause of failure via the exception they throw from HostResolveImportedModule. In any case, this exception causes an linking failure, which as before results in _A_'s [[Status]] remaining `"unlinked"`.</p>+    <p>In this scenario, module _A_ declares a dependency on some other module, but no Module Record exists for that module, i.e. HostResolveImportedModule throws an exception when asked for it. This could occur for a variety of reasons, such as the corresponding resource not existing, or the resource existing but ParseModule throwing an exception when trying to parse the resulting source text. Hosts can choose to expose the cause of failure via the exception they throw from HostResolveImportedModule. In any case, this exception causes a linking failure, which as before results in _A_'s [[Status]] remaining ~unlinked~.</p> -    <p>Now consider a module graph with a cycle:</p>+    <p>Lastly, consider a module graph with a cycle:</p>      <emu-figure id="figure-module-graph-cycle" caption="A cyclic module graph">       <img alt="A module graph in which module A depends on module B and C, but module B also depends on module A" width="181" height="121" src="img/module-graph-cycle.svg">     </emu-figure> -    <p>Here we assume that the entry point is module _A_, so that the host proceeds by calling _A_.Link(), which performs InnerModuleLinking on _A_. This in turn calls InnerModuleLinking on _B_. Because of the cycle, this again triggers InnerModuleLinking on _A_, but at this point it is a no-op since _A_.[[Status]] is already `"linking"`. _B_.[[Status]] itself remains `"linking"` when control gets back to _A_ and InnerModuleLinking is triggered on _C_. After this returns with _C_.[[Status]] being `"linked"` , both _A_ and _B_ transition from `"linking"` to `"linked"` together; this is by design, since they form a strongly connected component.</p>+    <p>Here we assume that the entry point is module _A_, so that the host proceeds by calling _A_.Link(), which performs InnerModuleLinking on _A_. This in turn calls InnerModuleLinking on _B_. Because of the cycle, this again triggers InnerModuleLinking on _A_, but at this point it is a no-op since _A_.[[Status]] is already ~linking~. _B_.[[Status]] itself remains ~linking~ when control gets back to _A_ and InnerModuleLinking is triggered on _C_. After this returns with _C_.[[Status]] being ~linked~ , both _A_ and _B_ transition from ~linking~ to ~linked~ together; this is by design, since they form a strongly connected component.</p>      <p>An analogous story occurs for the evaluation phase of a cyclic module graph, in the success case.</p> -    <p>Now consider a case where _A_ has an linking error; for example, it tries to import a binding from _C_ that does not exist. In that case, the above steps still occur, including the early return from the second call to InnerModuleLinking on _A_. However, once we unwind back to the original InnerModuleLinking on _A_, it fails during ModuleDeclarationEnvironmentSetup, namely right after _C_.ResolveExport(). The thrown *SyntaxError* exception propagates up to _A_.Link, which resets all modules that are currently on its _stack_ (these are always exactly the modules that are still `"linking"`). Hence both _A_ and _B_ become `"unlinked"`. Note that _C_ is left as `"linked"`.</p>

Hm, it doesnt look like this line is different beyond the changes to "linked" -> ~linked~ and similar?

codehag

comment created time in 6 hours

Pull request review commenttc39/proposal-top-level-await

update spec.html to current spec

 <h1>Example Source Text Module Record Graphs</h1>       <img alt="A module graph in which module A depends on a missing (unresolvable) module, represented by ???" width="121" height="121" src="img/module-graph-missing.svg">     </emu-figure> -    <p>In this scenario, module _A_ declares a dependency on some other module, but no Module Record exists for that module, i.e. HostResolveImportedModule throws an exception when asked for it. This could occur for a variety of reasons, such as the corresponding resource not existing, or the resource existing but ParseModule throwing an exception when trying to parse the resulting source text. Hosts can choose to expose the cause of failure via the exception they throw from HostResolveImportedModule. In any case, this exception causes an linking failure, which as before results in _A_'s [[Status]] remaining `"unlinked"`.</p>+    <p>In this scenario, module _A_ declares a dependency on some other module, but no Module Record exists for that module, i.e. HostResolveImportedModule throws an exception when asked for it. This could occur for a variety of reasons, such as the corresponding resource not existing, or the resource existing but ParseModule throwing an exception when trying to parse the resulting source text. Hosts can choose to expose the cause of failure via the exception they throw from HostResolveImportedModule. In any case, this exception causes a linking failure, which as before results in _A_'s [[Status]] remaining ~unlinked~.</p> -    <p>Now consider a module graph with a cycle:</p>+    <p>Lastly, consider a module graph with a cycle:</p>      <emu-figure id="figure-module-graph-cycle" caption="A cyclic module graph">       <img alt="A module graph in which module A depends on module B and C, but module B also depends on module A" width="181" height="121" src="img/module-graph-cycle.svg">     </emu-figure> -    <p>Here we assume that the entry point is module _A_, so that the host proceeds by calling _A_.Link(), which performs InnerModuleLinking on _A_. This in turn calls InnerModuleLinking on _B_. Because of the cycle, this again triggers InnerModuleLinking on _A_, but at this point it is a no-op since _A_.[[Status]] is already `"linking"`. _B_.[[Status]] itself remains `"linking"` when control gets back to _A_ and InnerModuleLinking is triggered on _C_. After this returns with _C_.[[Status]] being `"linked"` , both _A_ and _B_ transition from `"linking"` to `"linked"` together; this is by design, since they form a strongly connected component.</p>+    <p>Here we assume that the entry point is module _A_, so that the host proceeds by calling _A_.Link(), which performs InnerModuleLinking on _A_. This in turn calls InnerModuleLinking on _B_. Because of the cycle, this again triggers InnerModuleLinking on _A_, but at this point it is a no-op since _A_.[[Status]] is already ~linking~. _B_.[[Status]] itself remains ~linking~ when control gets back to _A_ and InnerModuleLinking is triggered on _C_. After this returns with _C_.[[Status]] being ~linked~ , both _A_ and _B_ transition from ~linking~ to ~linked~ together; this is by design, since they form a strongly connected component.</p>      <p>An analogous story occurs for the evaluation phase of a cyclic module graph, in the success case.</p> -    <p>Now consider a case where _A_ has an linking error; for example, it tries to import a binding from _C_ that does not exist. In that case, the above steps still occur, including the early return from the second call to InnerModuleLinking on _A_. However, once we unwind back to the original InnerModuleLinking on _A_, it fails during ModuleDeclarationEnvironmentSetup, namely right after _C_.ResolveExport(). The thrown *SyntaxError* exception propagates up to _A_.Link, which resets all modules that are currently on its _stack_ (these are always exactly the modules that are still `"linking"`). Hence both _A_ and _B_ become `"unlinked"`. Note that _C_ is left as `"linked"`.</p>

Of course! I didn't realize they were additions. I tried to transfer everything that was <ins>

This is a meta discussion, personally I think doing this by hand is too much (this is the first time I do it, might be an experience thing). It results in unspoken conventions that might not be recognized by new reviewers. It feels like -- we have diffing systems, They do this much better than humans. It would be great to be able to use them to our advantage and have a base spec.html file, along with a diff file, and have ecmarkup recognize +/- at the beginning of a line. It would really help situations like this. Then we could have a plain spec.html file which has the spec as it would be written, and a spec-diff.html file that shows the changes from the branch point. But again, not something I have done very often so it would be interesting to hear what other people think.

codehag

comment created time in 7 hours

push eventcodehag/ecma262

codehag

commit sha f189778e17ba8b315777d270333ba4b3502e435f

add discourse to readme

view details

push time in a day

Pull request review commenttc39/ecma262

add discourse to readme

 After cloning, do `npm install` to set up your environment. You can then do `npm  ## Community -* [Es-discuss mailing list](https://esdiscuss.org): Mailing list for ECMAScript discussions-* IRC: #tc39 on Freenode ([instructions](https://freenode.net/kb/answer/chat))+* [ES discourse](https://es.discourse.group/): Discourse for ECMAScript discussion and questions.+* [Es-discuss mailing list](https://esdiscuss.org): Mailing list for ECMAScript discussions.

These two lines just got an added period

codehag

comment created time in 2 days

PR opened tc39/ecma262

Reviewers
add discourse to readme

Noticed the discourse is missing from the community section of the readme

+3 -2

0 comment

1 changed file

pr created time in 2 days

create barnchcodehag/ecma262

branch : add-discourse

created branch time in 2 days

pull request commenttc39/ecma262

add searchfox link to readme

Should I wait for all 4 editors to sign off here?

codehag

comment created time in 2 days

push eventcodehag/ecma262

yulia

commit sha 88df31547d2c5562614b9b0a7f281c51f548756d

Update README.md Co-authored-by: Kevin Gibbons <bakkot@gmail.com>

view details

push time in 2 days

push eventcodehag/ecma262

yulia

commit sha 3be84682ffcc8e2a8c8f893d69e040453b046607

Update README.md Co-authored-by: jmdyck <jmdyck@ibiblio.org>

view details

push time in 3 days

PR opened tc39/ecma262

add searchfox link to readme

I realized that the historical view of the spec might not be accessible for most people, so this PR adds a link to the readme. Related to #1999

+2 -0

0 comment

1 changed file

pr created time in 3 days

create barnchcodehag/ecma262

branch : searchfox

created branch time in 3 days

fork codehag/ecma262

Status, process, and documents for ECMA-262

https://tc39.es/ecma262/

fork in 3 days

issue closedtc39/ecma262

thinking about spec.html

This is just an idea...

my problem: I have a hard time knowing why some line in the spec changed. My current process is to use git blame on spec.html, search for the line, find the most recent change, checkout that commit, search for the line, repeat.

I am having to rely a lot of git blame in order to see how / where the spec changes. I also know that people have built their own tools to track this. https://arai-a.github.io/ecma262-compare/

So, I am wondering if other people share this issue and if we should tackle this somehow. For example, splitting spec.html into chapters that can be indexed by github, so we can track the history of changes through the file. Then, we could have a build step that takes all of these files and combines them into the monster spec.

Is this a problem for others?

closed time in 4 days

codehag

issue commenttc39/ecma262

thinking about spec.html

my issue has been resolved.

codehag

comment created time in 4 days

issue commenttc39/ecma262

thinking about spec.html

Rejoice! https://searchfox.org/ecma262/source/spec.html

(and over over the grey bar on the left. You can click through to previous diffs and examine the change over time)

codehag

comment created time in 4 days

push eventtc39/agendas

codehag

commit sha 7116522ec92825b52b10a93bfe6f14a16c4f20e7

remove weakrefs

view details

yulia

commit sha 77beda4ebeee5331a8e169537e6aca2243b0e88a

Merge pull request #765 from codehag/remove-weakrefs remove weakrefs

view details

push time in 5 days

PR merged tc39/agendas

remove weakrefs
+0 -1

0 comment

1 changed file

codehag

pr closed time in 5 days

PR opened tc39/agendas

remove weakrefs
+0 -1

0 comment

1 changed file

pr created time in 5 days

create barnchcodehag/agendas

branch : remove-weakrefs

created branch time in 5 days

push eventsyg/proposal-rm-builtin-subclassing

Shu-yu Guo

commit sha 6285acabe293e81863a80482b74cddc9646ef1a7

Clarify that the RegExp-like protocol is not proposed to be removed

view details

codehag

commit sha cbacde216dbff74a8b77a8bfa6149ec25c8f32a5

add examples

view details

yulia

commit sha 370625f9765bd7d0a1565531ae6ff1a8d6109ed3

Merge pull request #7 from codehag/add-examples add examples

view details

push time in 5 days

PR merged syg/proposal-rm-builtin-subclassing

add examples

Hopefully addresses any ambiguities such as those raised by #6

+162 -18

0 comment

1 changed file

codehag

pr closed time in 5 days

Pull request review commentsyg/proposal-rm-builtin-subclassing

add examples

 Type I is used by user libraries, as well as by the web platform in WebIDL and D  Type II is supported if built-in methods create new instances of the subclass. For example, if `Array.prototype.map` or `Array.from` returns instances of subclasses of `Array`. Support for this is provided by delegating to `this.constructor[`@@species`]` inside built-in methods for the default @@species getter.

should we open an issue around this? cc @syg

codehag

comment created time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha cbacde216dbff74a8b77a8bfa6149ec25c8f32a5

add examples

view details

push time in 5 days

Pull request review commentsyg/proposal-rm-builtin-subclassing

add examples

+# RegExp changes

yep

codehag

comment created time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha b3b332b4f0e67ac4e45b9d5b7584340b1dffecee

add examples

view details

push time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha 14183995a8ec2b7160cd91d2889d782ba4784830

add examples

view details

push time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha 2ea557b79b868e2e1b69cd0b3f04fe9c3092129b

add examples

view details

push time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

Shu-yu Guo

commit sha 56cb9dd2bd5b5f3c84c9634cedeee2e387805d4a

Clarify Type II vs III some more

view details

Shu-yu Guo

commit sha 6285acabe293e81863a80482b74cddc9646ef1a7

Clarify that the RegExp-like protocol is not proposed to be removed

view details

codehag

commit sha 755085aceaa8baa3203145803a16de6eb443790a

add examples

view details

push time in 5 days

Pull request review commentsyg/proposal-rm-builtin-subclassing

add examples

 Supporting built-in subclassing has also negatively affected authoring of new bu  Type I is supported if creating subclasses of built-ins is possible. For example, if derived class can call `super()`. Support for this is provided via `new.target`. +### Example++```js+class A extends Array {+  constructor() {+    super();+  }+}+A.from([1,2,3])     // return type: Array

Don't know if i got this right now...

codehag

comment created time in 5 days

Pull request review commentsyg/proposal-rm-builtin-subclassing

add examples

+# RegExp changes++```diff+21.2.3.1 RegExp ( pattern, flags )++The following steps are taken:++-    1. Let patternIsRegExp be ? IsRegExp(pattern).

I think this has been resolved. I will remove this file.

codehag

comment created time in 5 days

Pull request review commentsyg/proposal-rm-builtin-subclassing

Clarify that the RegExp-like protocol is not proposed to be removed

 let ma = MyArray.from([1,2,3]);  RegExp subclassing machinery involves both @@species and dynamic property lookups on the `this` value in various prototype methods. Property lookups will be removed in favor of internal slots. @@species will be removed in favor of creating `RegExp` objects in the current Realm. -### Constructor--- The `RegExp(` _pattern_, _flags_ `)` constructor will no longer check for `IsRegExp(` _pattern_ `)`.

for posterity: I was a little surprised that this would be removed. I thought that there would just be a notice that @@match is not removed, but just not really used.

But this is fine. @jandem said that afahk it isn't a hot path.

syg

comment created time in 5 days

push eventtc39/agendas

codehag

commit sha 08686f87b7b371ba94eeed0aa30341547d1b862e

add iterator helpers discussion

view details

yulia

commit sha 18414786a15b793ecb7d274e6008cd5260b38b2b

Merge pull request #759 from codehag/iterator-helpers add iterator helpers discussion

view details

push time in 5 days

PR merged tc39/agendas

add iterator helpers discussion
+2 -2

0 comment

1 changed file

codehag

pr closed time in 5 days

PR opened tc39/agendas

add iterator helpers discussion
+2 -2

0 comment

1 changed file

pr created time in 5 days

create barnchcodehag/agendas

branch : iterator-helpers

created branch time in 5 days

issue commentsyg/proposal-rm-builtin-subclassing

Editorial suggestion: Explain what stays the same in the README

@@match is more like a protocol IMO and not about subclassing per se. Removal of them is a different web compat question and language design question than trying to remove subclassing. For those reasons this proposal doesn't seek to remove Symbol.match.

We are fine with this. The main complexity we have around RegExp is checking these properties are not defined on String.prototype so that we can optimize the non-regexp case.

All that said I'm not proposing to remove them here as a tactical thing. There's enough compat risk here already.

I agree with this. The proposal, as is, is already pretty daunting. If this is successful we can look at other interventions in the future.

cc @jandem as he knows more about this area.

littledan

comment created time in 5 days

push eventtc39/agendas

codehag

commit sha b7265e2e02ff4d46eecee8f60fda849fdca0e44a

yulia will present

view details

yulia

commit sha 953f747ac1e1a50ab402f4bc7a7aa918ea89faff

Merge pull request #757 from codehag/add-subclassing-proposal yulia will present

view details

push time in 5 days

PR merged tc39/agendas

yulia will present
+1 -1

0 comment

1 changed file

codehag

pr closed time in 5 days

PR opened tc39/agendas

yulia will present
+1 -1

0 comment

1 changed file

pr created time in 5 days

push eventcodehag/agendas

codehag

commit sha b7265e2e02ff4d46eecee8f60fda849fdca0e44a

yulia will present

view details

push time in 5 days

push eventtc39/agendas

codehag

commit sha 8ecbdbebb6141644f21d7ccdbd41b92671664e63

add sublcassing removal proposal; pending approval from shu

view details

yulia

commit sha 8e46cf48436f8f9187358d83c98bcf807e159a1f

Merge pull request #756 from codehag/add-subclassing-proposal add sublcassing removal proposal

view details

push time in 5 days

PR merged tc39/agendas

add sublcassing removal proposal

This is a placeholder for now, waiting on Shu's ok for adding this...

+1 -0

1 comment

1 changed file

codehag

pr closed time in 5 days

pull request commenttc39/agendas

add sublcassing removal proposal

shu said it was ok

codehag

comment created time in 5 days

PR opened tc39/agendas

Reviewers
add sublcassing removal proposal; pending approval from shu

This is a placeholder for now, waiting on Shu's ok for adding this...

+1 -0

0 comment

1 changed file

pr created time in 5 days

PR opened tc39/agendas

Reviewers
split out cleanupSome proposal

Not sure this is the right place for the discussion, but I want to propose splitting cleanupSome from the weakrefs proposal to its own stage 3 proposal, so that we do not get blocked with weakrefs.

+2 -0

0 comment

1 changed file

pr created time in 5 days

create barnchcodehag/agendas

branch : add-subclassing-proposal

created branch time in 5 days

create barnchcodehag/agendas

branch : weakrefs

created branch time in 5 days

fork codehag/agendas

TC39 meeting agendas

fork in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha 8ac664ddf0c9473868b1004184677108782482f1

add examples

view details

push time in 5 days

push eventcodehag/proposal-rm-builtin-subclassing

codehag

commit sha 2ba3a852c182f3d2f3c0963448c590ad28be55a4

add examples

view details

push time in 5 days

PR opened syg/proposal-rm-builtin-subclassing

add examples

Hopefully addresses any ambiguities such as those raised by #6

+175 -6

0 comment

2 changed files

pr created time in 5 days

create barnchcodehag/proposal-rm-builtin-subclassing

branch : add-examples

created branch time in 5 days

PR opened tc39/test262

update comments in instn-once.js

Very minor, update comment related to this test.

+9 -9

0 comment

1 changed file

pr created time in 7 days

create barnchcodehag/test262

branch : update-instn-once.js

created branch time in 7 days

issue commenttc39/ecma262

thinking about spec.html

I spoke with the searchfox folks, and they said it should be possible to make a render of the spec file. The bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1639666

codehag

comment created time in 7 days

fork codehag/test262

Official ECMAScript Conformance Test Suite

fork in 7 days

push eventcodehag/proposal-top-level-await

codehag

commit sha 8b789d56f49925cb920157e2b2f232f91e98fdd8

update spec.html to current spec

view details

push time in 7 days

push eventcodehag/proposals

codehag

commit sha a7e7bc5faeaa0017c1d34f5bb9db68338cd68f9a

update display names

view details

yulia

commit sha f8d83ccefe32b15a7bcbed6a064e7b2cf506fc73

Merge pull request #5 from codehag/mozilla update display names

view details

push time in 7 days

PR merged codehag/proposals

update display names
+1 -1

0 comment

1 changed file

codehag

pr closed time in 7 days

PR opened codehag/proposals

update display names
+1 -1

0 comment

1 changed file

pr created time in 7 days

push eventcodehag/proposals

codehag

commit sha a7e7bc5faeaa0017c1d34f5bb9db68338cd68f9a

update display names

view details

push time in 7 days

issue commenttc39/ecma262

thinking about spec.html

Arai’s comment might work, we could do something like searchfox.

On Tue 19. May 2020 at 19:06, Kevin Gibbons notifications@github.com wrote:

We can create a multi-page rendering of the spec without splitting spec.html, just as we could create a multi-page spec.html without splitting the rendering of the spec. Let's keep the two separate. Creating a multi-page rendering of the spec is tracked in tc39/ecmarkup#151 https://github.com/tc39/ecmarkup/issues/151.

(PRs welcome for tc39/ecmarkup#151 https://github.com/tc39/ecmarkup/issues/151, by the way; I'd be happy to work with anyone who wants to contribute. I'll probably get to it eventually myself, but I have higher priorities at the moment.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tc39/ecma262/issues/1999#issuecomment-630954418, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNYEJYMQU5WQJQHWT75MO3RSK4AHANCNFSM4NE64TYA .

codehag

comment created time in 8 days

push eventcodehag/proposal-top-level-await

codehag

commit sha ac878d4ab6b911f0312f4145ab7e47f1218aee29

update spec.html to current spec

view details

push time in 8 days

PR opened tc39/proposal-top-level-await

update spec.html to current spec

Hi folks,

This partially addresses my issue #139 where I was having a hard time seeing what was different between the proposal and the existing spec. There are a couple of changes that have happened in the last year which were not merged into this spec. I tried to get all of them.

The biggest one is that TopLevelEvaluationJob no longer exists (https://tc39.es/proposal-top-level-await/#sec-toplevelmoduleevaluationjob). It is not in this pull request either, because I wasn't sure which part of thee spec this would now touch. It would be great to update this so i have a better idea while implementing this.

the other significant change is https://tc39.es/proposal-top-level-await/#sec-source-text-module-record-execute-module -- in the original, the change was quite small, but now it is larger. I don't know if this is accurate.

I think we could do with some tooling to make these diffs easier... Looking forward to peoples comments

+292 -598

0 comment

1 changed file

pr created time in 8 days

PR opened codehag/proposal-top-level-await

my changes

This is just an example of the changes to the spec for the proposal

+78 -41

0 comment

1 changed file

pr created time in 8 days

create barnchcodehag/proposal-top-level-await

branch : all-deletions

created branch time in 8 days

push eventcodehag/proposal-top-level-await

codehag

commit sha 9e55b42e3bc40f9db110247daaccdf031d588480

update spec.html to current spec

view details

push time in 8 days

issue commenttc39/proposal-top-level-await

Issues with spec text diff rendering?

I think one of the issues is that this is also out of date with the existing spec.

It is the first time i saw this convention and I found it a bit surprising... but it is also really annoying to annotate everything.

codehag

comment created time in 8 days

PR closed tc39/proposal-top-level-await

update spec.html to current spec

This is just to get the thing to render online

+167 -527

0 comment

1 changed file

codehag

pr closed time in 8 days

PR opened tc39/proposal-top-level-await

update spec.html to current spec

This is just to get the thing to render online

+167 -527

0 comment

1 changed file

pr created time in 8 days

create barnchcodehag/proposal-top-level-await

branch : update-spec

created branch time in 8 days

issue openedtc39/ecma262

thinking about spec.html

This is just an idea...

my problem: I have a hard time knowing why some line in the spec changed. My current process is to use git blame on spec.html, search for the line, find the most recent change, checkout that commit, search for the line, repeat.

I am having to rely a lot of git blame in order to see how / where the spec changes. I also know that people have built their own tools to track this. https://arai-a.github.io/ecma262-compare/

So, I am wondering if other people share this issue and if we should tackle this somehow. For example, splitting spec.html into chapters that can be indexed by github, so we can track the history of changes through the file. Then, we could have a build step that takes all of these files and combines them into the monster spec.

Is this a problem for others?

created time in 8 days

issue openedtc39/proposal-top-level-await

Issues with spec text diff rendering?

Is anyone else having issues with how the spec text is rendering? New sections are not being highlit as green in the rendered version, so I end up having to read this a lot closer.

created time in 8 days

push eventcodehag/jsparagus

codehag

commit sha ee3af2695d4d6ccf219cb477a4bc945e5cdedb6c

[WIP]Add metric for ci completion

view details

push time in 12 days

issue openedmozilla-spidermonkey/jsparagus

Document control_structures.rs

Control structures is partially documented, but not fully. I would like to go through and document it more full, and split it up into components and helpers if necessary.

created time in 12 days

issue openedmozilla-spidermonkey/jsparagus

Implement Error Trait

Based off the work in https://github.com/mozilla-spidermonkey/jsparagus/issues/502

This issue is to track moving the error checker trait off of ast builder, and add it directly to the parser.

parts:

  • create an error builder trait, that mirrors ast builder trait
  • remove error checker trait from ast builder, and use it as the base for an error builder class
  • move context_metadata from ast builder to error builder
  • add a new trait on the parser

created time in 12 days

issue openedbocoup/test262-report-issue-tracker

Percentages look wrong

Summary

Percentages are showing over 100% compliance. I think this just happened, I was looking at it yesterday and the numbers were right... ...

Expected behavior

Percentages show less than 100% for not fully complying browsers, up to 100% ...

Actual behavior

Screenshot 2020-05-15 at 14 55 22

...

Steps to reproduce

Load the page ...

Environment

MacOS, firefox ...

created time in 12 days

push eventcodehag/jsparagus

codehag

commit sha 700931dee957a7d1163a69bb8bea7c5886bd0654

[WIP]Add metric for ci completion

view details

push time in 12 days

issue closedmozilla-spidermonkey/jsparagus

Support logical assignment proposal

https://github.com/tc39/proposal-logical-assignment

the following testcase fails:

  • test262/language/expressions/logical-assignment/lgcl-nullish-whitespace.js
  • test262/language/expressions/logical-assignment/lgcl-and-assignment-operator-unresolved-rhs-put.js
  • test262/language/expressions/logical-assignment/lgcl-nullish-assignment-operator.js
  • test262/language/expressions/logical-assignment/lgcl-and-assignment-operator.js
  • test262/language/expressions/logical-assignment/lgcl-or-assignment-operator-unresolved-rhs.js
  • test262/language/expressions/logical-assignment/lgcl-and-whitespace.js
  • test262/language/expressions/logical-assignment/lgcl-and-assignment-operator-unresolved-rhs.js
  • test262/language/expressions/logical-assignment/lgcl-nullish-assignment-operator-unresolved-rhs-put.js
  • test262/language/expressions/logical-assignment/lgcl-or-assignment-operator-unresolved-rhs-put.js
  • test262/language/expressions/logical-assignment/lgcl-nullish-assignment-operator-unresolved-rhs.js
  • test262/language/expressions/logical-assignment/lgcl-or-whitespace.js
  • test262/language/expressions/logical-assignment/lgcl-or-assignment-operator.js
  • non262/expressions/short-circuit-compound-assignment-const.js
  • non262/expressions/short-circuit-compound-assignment.js

closed time in 13 days

arai-a

push eventmozilla-spidermonkey/jsparagus

codehag

commit sha d7c4f05f02fd96254cd2ac3caf403341bef2fcb7

implement logical assignment in lexer and return not implemented; partially addresses #498

view details

yulia

commit sha 42461da9b92772240af311c5e2c324b4cc604402

Merge pull request #518 from codehag/logical-assignment implement logical assignment in lexer and return not implemented; partially addresses #498

view details

push time in 13 days

PR merged mozilla-spidermonkey/jsparagus

implement logical assignment in lexer and return not implemented; partially addresses #498

😬 to stop the failing tests.

It is reserve but I was having a hard time focusing and this was staring at me.

+91 -18

0 comment

7 changed files

codehag

pr closed time in 13 days

push eventcodehag/proposals

codehag

commit sha e3ee8ae5abb7167f7e5e7100ee312baeb842a1b0

update top level await

view details

yulia

commit sha 452203f4d62fc533d3cf38538aed9830d7182450

Merge pull request #4 from codehag/mozilla update top level await

view details

push time in 13 days

PR merged codehag/proposals

update top level await
+1 -1

0 comment

1 changed file

codehag

pr closed time in 13 days

PR opened codehag/proposals

update top level await
+1 -1

0 comment

1 changed file

pr created time in 13 days

push eventcodehag/proposals

codehag

commit sha e3ee8ae5abb7167f7e5e7100ee312baeb842a1b0

update top level await

view details

push time in 13 days

push eventcodehag/jsparagus

codehag

commit sha 9500eb3d9594eea112dce39df7bd45c8c0ae0470

[WIP]Add metric for ci completion

view details

push time in 13 days

PR opened mozilla-spidermonkey/jsparagus

Reviewers
implement logical assignment in lexer and return not implemented; partially addresses #498

😬 to stop the failing tests.

It is reserve but I was having a hard time focusing and this was staring at me.

+91 -18

0 comment

7 changed files

pr created time in 13 days

create barnchcodehag/jsparagus

branch : logical-assignment

created branch time in 13 days

more