archives

« Bugzilla Issues Index

#3427 — Infeasible semantic rules of ES5

• bug_id: 3427
• creation_ts: 2014-12-08 15:19:00 -0800
• short_desc: Infeasible semantic rules of ES5
• delta_ts: 2015-10-03 18:57:28 -0700
• product: ECMA-262, Editions 5 and 5.1
• component: technical content
• version: Edition 5.1
• rep_platform: All
• op_sys: All
• bug_status: RESOLVED
• resolution: FIXED
• priority: Normal
• bug_severity: enhancement
• everconfirmed: true
• reporter: Daejun Park
• assigned_to: Allen Wirfs-Brock
• cc: brterlso

---

• commentid: 10969
• comment_count: 0
• attachid: 75
• who: Daejun Park
• bug_when: 2014-12-08 15:19:03 -0800

Created attachment 75
Quick explanation why each semantic rules are infeasible

I think that the following semantic rules are not feasible to reach.

- 8.7.2 PutValue (V, W) - [[Put]], Step 4.a
- 8.7.2 PutValue (V, W) - [[Put]], Step 4.b
- 10.2.1.1.4 GetBindingValue(N,S) - Step 3.a
- 10.2.1.1.5 DeleteBinding (N) - Step 2
- 10.2.1.2.4 GetBindingValue(N,S) - Step 4.a
- 10.6 Arguments Object - [[DefineOwnProperty]], Step 4.a, else-branch

I attached quick explanations why they are infeasible for each cases.


I found these infeasible semantic rules when systematically measuring test coverage of test262. I found several missing semantic rules that are not covered by test262, and attempted to manually write test programs for each cases, but failed to find tests for the above cases. For the other cases, I succeeded in finding tests, which already reported in Bug 3426:
https://bugs.ecmascript.org/show_bug.cgi?id=3426

For more details, please refer to the following page:
https://github.com/kframework/javascript-semantics/blob/master/test262-coverage/README.md


Thanks,
Daejun

---

• commentid: 12796
• comment_count: 1
• who: Allen Wirfs-Brock
• bug_when: 2015-02-16 18:08:49 -0800

thanks, nice analysis.

I checked these against the ES6 spec. Mostly they have already been taken care of via refactoring that has taken place since ES5.1.

Also, the existence of proxies means that object environment records are less predicable.

But I did change the hasBinding test in declarative binding record DeleteBinding into an assertion.

---

• commentid: 14768
• comment_count: 2
• who: Brian Terlson
• bug_when: 2015-10-03 18:57:28 -0700

Seems fixed.