| 14:28 | <jmdyck> | Michael Ficarra: "test262-parser-tests has a "fail" directory which is spiritually the same": No, "fail" there doesn't mean "it's okay for your implementation to fail this test", it means "your implementation should raise a SyntaxError because this test doesn't conform to the ES grammar". |
| 14:29 | <jmdyck> | (test262-parser-tests' use of "pass" and "fail" as categories of tests is annoying: makes it difficult to talk about passing or failing a test.) |
| 14:31 | <devsnek> | jmdyck: but you could have a syntax extension |
| 14:31 | <jmdyck> | yeah, that's why i said "should" rather than "must" |
| 14:36 | <Michael Ficarra> | jmdyck: that's the point, it's similar to the proposed test262 assertions on non-existence of extensions to built-ins |
| 14:37 | <jmdyck> | ah, okay. |
| 14:38 | <jmdyck> | but then I imagine that's true of the "early" tests as well |
| 14:38 | <Michael Ficarra> | is an implementation allowed to ignore an early error? I don't think so |
| 14:38 | <Michael Ficarra> | if so, though, then yes that is also analagous |
| 14:40 | <jmdyck> | If you can ignore the grammar, then why not ignore an early error? But it's true the spec isn't very clear. |
| 14:46 | <jmdyck> | But e.g. "Forbidden Extensions" says "When processing strict mode code, an implementation must not relax the early error rules of 12.8.3.1." which suggests that it is okay to relax other early error rules. |
| 22:30 | <Michael Ficarra> | jmdyck: we might want to work on clarifying the answer to that, editorially |
| 22:30 | <Michael Ficarra> | at least, once we know for sure what committee intent is |
| 23:19 | <jmdyck> | Aye, there's the rub. |
| 23:20 | <jmdyck> | https://github.com/tc39/ecma262/issues/2432 gets into roughly that area. |
| 23:32 | <jmdyck> | https://github.com/tc39/ecma262/issues/1323 is another take. |