00:54 | <devsnek> | what is one supposed to do when the spec says "If R contains any GroupName" or "ith capture of R" |
00:55 | <devsnek> | implicitly reparse the [[OriginalSource]] of R? |
00:57 | <Bakkot> | the spec doesn't really tell you how you should implement things, just what their observable behavior should be |
00:58 | <Bakkot> | reparsing would work; in practice I am pretty sure everyone just stores things on the internal representation of the regex |
01:00 | <devsnek> | i mean that it's not really defined what "r contains any groupname means" |
01:00 | <devsnek> | move the last quote over one word :( |
01:03 | <shu> | that's just the static semantics for Contains, no? |
01:03 | <Bakkot> | shu: the problem here is that R is a RegExp instance, not a parse node |
01:04 | <shu> | ah |
01:06 | <shu> | but the original source is kept around in the spec machinery i imagine |
01:06 | <shu> | through enough unwrappings of [[OriginalSource]] |
01:54 | <devsnek> | shu: that's a source text though, not a parse node |
15:48 | <jmdyck> | devsnek: my guess is, that was written without thinking about what it meant in terms of the spec's model. |
15:51 | <jmdyck> | RegExp instance maybe needs a [[PatternContainsAGroupName]] slot |
21:07 | <rkirsling> | wow, does eshost do some sort of weird script-wrapping? |
21:08 | <rkirsling> | `print('x:', 'y');` collapses for just JSC, but `'x', 'y';` collapses for everyone |
21:10 | <rkirsling> | (of course both of those are totally fine without eshost) |
21:23 | <devsnek> | rkirsling: it tries to parse errors using regex |
21:23 | <devsnek> | the regex for jsc and quickjs are apparently lax enough to just match `x: y` |
21:23 | <devsnek> | https://gc.gy/54690676.png |
21:25 | <rkirsling> | QuickJS is one thing but it seems like it's trying to have JSC resolve `y`? |
21:25 | <devsnek> | wdym |
21:25 | <rkirsling> | dunno why else it would say `y: undefined` |
21:26 | <devsnek> | the group its trying to access is undefined |
21:26 | <devsnek> | on the regex |
21:26 | <rkirsling> | oh hm |
21:26 | <rkirsling> | are you talking about a regex inside JSC or something for JSC that eshost has? |
21:26 | <devsnek> | eshost has it |
21:26 | <devsnek> | i don't really know why it does |
21:27 | <devsnek> | maybe a long time ago the shells exited 0 even if they failed |
21:27 | <devsnek> | this reminds me again that i was going to try to modernize eshost |
21:28 | <rkirsling> | this is causing at least one bogus test262 result :( |
21:29 | <rkirsling> | I mean we're failing that test anyway but it prevents us from even trying |
21:30 | <devsnek> | https://github.com/bterlson/eshost/blob/master/lib/agents/jsc.js |
21:31 | <devsnek> | `x: y\n` matches this regex |
21:35 | <rkirsling> | wow |
21:35 | <rkirsling> | that is horrible |
21:35 | <rkirsling> | so yeah `print('x: ', 'y')` is even okay |
21:36 | <rkirsling> | I don't understand what needs to be done there |
21:38 | <devsnek> | i don't really know why any error parsing is needed |
21:38 | <devsnek> | i would just make stderr red and call it a day |
21:40 | <Bakkot> | I think JSC did previously exit with 0 on error |
21:43 | <devsnek> | all the engines have it |
21:43 | <devsnek> | maybe its so it turns red for test262 printing out Test262Errors |
21:50 | <rkirsling> | https://github.com/bterlson/eshost/issues/106 |
22:23 | <devsnek> | rkirsling: what happens if you just remove it and run test262 |
22:23 | <devsnek> | like does anything thats supposed to be detected as failure accidentally succeed |
22:24 | <rkirsling> | could try in a bit |
22:36 | <Bakkot> | request for feedback on a possible editorial change: https://github.com/tc39/ecma262/issues/1950 |
22:38 | <devsnek> | i've spent so much time over the past week ctrl+f'ing around the document while trying to implement various operations for engine262 |
22:39 | <devsnek> | this would be so nice |