| 04:15 | <devsnek> | is ContainsArguments missing AsyncGenerator stuff |
| 04:22 | <bakkot> | devsnek: looks like, yup |
| 04:28 | <devsnek> | super is allowed in fields even without ClassHeritage? |
| 04:32 | <devsnek> | hm i guess its allowed in normal methods too |
| 04:32 | <devsnek> | weird |
| 04:33 | <bakkot> | even in regular objects, yeah |
| 04:34 | <bakkot> | ({ __proto__: { x: 0 }, m(){ return super.x; } }).m() returns 0 |
| 04:34 | <devsnek> | this language is quite odd |
| 05:04 | <devsnek> | hmm there are a few DefinePropertyOrThrow's missing either a ! or a ? in the various InstantiateFooFunctionExpression RS |
| 05:25 | <Jack Works> | |
| 05:27 | <bakkot> | devsnek: speaking very pedantically it's not required there; it happens that it doesn't throw, and you don't need the completion record, so it is not incorrect to just do the step and ignore the result rather than doing the step and asserting that the result is not abrupt |
| 05:27 | <devsnek> | would that be lawful evil or chaotic evil |
| 05:32 | <bakkot> | Jack Works: modulo some details about HomeObject, super.x mostly just means "access .x but on the prototype"; regular objects have prototypes too, so why shouldn't it be valid? |
| 08:36 | <Jack Works> | Oh I thought super is only valid in class body |
| 10:15 | <HE Shi-Jun> | Jack Works: Many people also think this in static method is invalid :P |
| 16:22 | <devsnek> | only 8 more failing tests :O |
| 16:44 | <devsnek> | solid 96% coverage of test262 now |