| 14:51 | <jorendorff> | Hi everyone - I'm curious about https://tc39.es/ecma262/#sec-script-semantics-runtime-semantics-evaluation Step 15 |
| 14:52 | <jorendorff> | Anyone know why it's like that? |
| 15:07 | <bradleymeck> | jorendorff: i think you mislinked w/e you wanted to show |
| 15:08 | <jorendorff> | darn |
| 15:08 | <jorendorff> | Thanks, I meant https://tc39.es/ecma262/#sec-runtime-semantics-scriptevaluation |
| 15:36 | <devsnek> | jorendorff: why it asserts that the stack is not empty? |
| 15:36 | <jorendorff> | Yes |
| 15:37 | <devsnek> | because the context from realm init should be on the stack |
| 15:38 | <jorendorff> | What is "realm init"? |
| 15:41 | <jmdyck> | InitializeHostDefinedRealm creates an execution context and pushes it onto the stack |
| 16:14 | <jorendorff> | huh. ok, and another spec, like the HTML spec, can pop that execution context and keep it around? |
| 16:14 | <jorendorff> | is it ever actually used? |
| 16:15 | <jorendorff> | it's weird because it seems like we should've asserted that on entry |
| 16:15 | <jorendorff> | but also because I don't understand what this is for |
| 16:21 | <jmdyck> | https://github.com/tc39/ecma262/pull/1597#discussion_r296465769 may help |
| 20:41 | <jorendorff> | That is helpful. |
| 21:00 | <devsnek> | why do we have tests that allow ID_Continue characters as the start of IdentifierName |
| 21:00 | <devsnek> | mathiasbynens: ^ |
| 21:00 | <bakkot> | presumably they are also ID_start? |
| 21:01 | <devsnek> | they are not |
| 21:01 | <bakkot> | link the test? |
| 21:01 | <devsnek> | language/identifiers/part-unicode-9.0.0.js |
| 21:11 | <bakkot> | that looks like a bug, yeah |
| 21:13 | <bakkot> | no wawit |
| 21:13 | <bakkot> | it's just hard to read |
| 21:13 | <bakkot> | it starts with `_` |
| 21:13 | <devsnek> | hmmm |
| 21:14 | <devsnek> | i guess that's why it wasn't matching ID_Start |
| 21:15 | <bakkot> | the message in the test is wrong though |
| 22:13 | <devsnek> | CreateDynamicFunction lists a bunch of conditions to throw syntax errors for |
| 22:13 | <devsnek> | but i'm thinking that maybe step 20.d covers all of them |
| 22:16 | <bakkot> | the supercall one at least is not, because it's an error for full functions, not for either parameters or the body |
| 22:16 | <bakkot> | my guess is that this is true for the others, without having looked |
| 22:20 | <devsnek> | oh hm |
| 22:20 | <devsnek> | that's kind of annoying |