15:18
<Jack Works>
label: {
    switch (true) { case true: break label }
    console.log(1)
}

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.

npm install 0o7-licensed-to-polyfill