15:18 | <Jack Works> |
1 not logged |
15:18 | <Jack Works> | that's very inconsistent |
15:30 | <Jack Works> | oh wait never mind |
17:21 | <devsnek> | looks like test262 is missing some coverage https://twitter.com/mild_sunrise/status/1439277173932806148 |
17:21 | <devsnek> | poor v8 https://gc.gy/8259149f-bc48-41c5-9efe-2297b987a302.png |
17:22 | <bakkot> | that's... huh |
17:23 | <devsnek> | it turned the literal into a string 😄 |
17:23 | <bakkot> | same deal with hex: ({ 0x7n: 0 }) -> {0x7: 0} |
17:28 | <devsnek> | quick someone wake shu up, sev 0 bug alert |
17:30 | <bakkot> | affects FNI too: Object.values(({ 0o7n: function(){} }))[0].name === '0o7' |
19:29 | <rkirsling> | wacky |
19:29 | <rkirsling> | does it just happen for the should-be-bigint cases? |
19:30 | <bakkot> | yeah it's specifically a bug in the parser for bigints |
19:30 | <bakkot> | that is, a bug in the parser for object literals in the bigint case |
19:30 | <bakkot> | specifically https://github.com/v8/v8/blob/894a36f9dd43a39ffdb3980bc7dac51e3399b06a/src/parsing/parser-base.h#L2294 |
19:31 | <rkirsling> | ahhh whoops haha |
20:09 | <ljharb> | hm, in the latest node repl it prints out [ 'Oo7n' ] |
20:10 | <bakkot> | leading character is a digit-0 not a letter-O |
20:11 | <ljharb> | ah k |
20:11 | <ljharb> | Object.keys({ 0o7n: 1 } makes [ '0o7' ] , gotcha |
20:38 | <justingrant> | If this bug is fixed and people are relying on the current behavior, does that mean that someone will have to publish a polyfill to get the current behavior back? If so, that would be so awesome.
|