01:22:48  * plutoniixjoined
01:23:20  * plutoniixquit (Max SendQ exceeded)
01:23:56  * plutoniixjoined
01:25:05  * plutoniixquit (Max SendQ exceeded)
01:25:32  * plutoniixjoined
03:00:48  * bradleymeckjoined
03:06:17  * bradleymeckquit (Quit: bradleymeck)
08:22:52  * Guest59_quit (Read error: Connection reset by peer)
08:23:49  * Guest59joined
08:33:34  * ilyaigpetrovjoined
08:56:30  * RT|Chatzillajoined
09:54:58  * plutoniixquit (Quit: Leaving)
11:15:37  * Cube8joined
12:47:09  * zvquit (Ping timeout: 240 seconds)
12:56:27  <s1341>it seems that expose_debug_as is no longer available on d8... what's going on with that?
13:04:15  * zvjoined
13:49:12  <caitp>s1341: the tests that still use the debug api include test/debugger/test-api.js
13:49:37  <caitp>which seems to implement the old debug.Debug api using a couple intrinsics
13:50:04  <s1341>so the debug.Debug api is gone?
13:50:12  * bradleymeckjoined
13:50:16  <caitp>I believe so, yeah
13:50:24  <caitp>but I haven't followed the v8-inspector work too closely
13:50:54  <s1341>caitp. ok. thanks for the info
14:28:07  * bradleymeckquit (Quit: bradleymeck)
14:33:56  <s1341>caitp i'm having trouble understanding how some builtins are called.
14:34:16  <s1341>caitp: can i pick your brain?
14:34:23  <caitp>go ahead
14:35:16  <s1341>caitp: how is this builtin called: https://chromium.googlesource.com/v8/v8/+/master/src/builtins/builtins-string.cc#362
14:36:40  <caitp>that's a code stub, I'm going to guess it's called if type feedback indicates both lhs and rhs of a == operation are strings
14:37:10  <s1341>caitp, any idea what code actually calls it? I can't seem to find a reference to any code which directly calls it
14:37:50  <s1341>the best I can find is a TFS_BUILTIN(StringEqual) in code-factory.cc
14:38:06  <s1341>is that calling my StringEqual?
14:40:36  <caitp>so, in code-stub-assembler.cc there's a macro op called Equal, which invokes the StringEqual stub if the lhs and rhs are both strings
14:41:20  <caitp>the Equal stub just calls that macro op, and implements the generic version of ==, eg when the compiler can't reduce it to a smaller inlineable operation
14:43:09  <s1341>i
14:43:25  <s1341>oh. i see. it does go through the CodeFactory::StringEqual...
14:46:46  <caitp>the interpreter will definitely call this if lhs and rhs are strings and the code is interpreted, dunno if it's reachable through the legacy pipeline
14:49:17  <caitp>looks like the legacy pipeline just uses CompareIC instead
14:49:32  <caitp>anyway, hope that helps
14:49:56  <s1341>caitp. i think it did. I was missing that the CodeFactory::XXX call the TF_BUILTINS...
14:52:22  * plutoniixjoined
14:52:51  * plutoniixquit (Max SendQ exceeded)
14:53:26  * plutoniixjoined
15:08:46  <s1341>caitp. ok i've gotten turned around again.
15:09:46  <s1341>what about this one: https://chromium.googlesource.com/v8/v8/+/master/src/builtins/builtins-string.cc#401
15:10:24  <s1341>I see the CodeFactory stub... and it's even called from compiler/effect-control-linearizer.cc
15:10:35  <s1341>caitp: but I can't seem to get that code to execute...
15:10:45  <caitp>that gets installed to String.prototype at https://chromium.googlesource.com/v8/v8/+/master/src/bootstrapper.cc#1575
15:11:04  <caitp>so, "foo".charCodeAt(0) calls it
15:12:07  <s1341>caitp: no. i think what's installed is StringPrototypeCharCodeAt...
15:12:35  <s1341>I'm looking at StringCharAt...
15:12:40  <caitp>ah, you're right in that case, one sec
15:12:54  <caitp>so yeah, StringCharCodeAt is another code stub
15:13:48  <caitp>looks like it's used by turbofan
15:14:36  <caitp>as part of lowering the StringCharCodeAt opcode, which I'm guessing comes from "foo"[0]
15:15:17  <s1341>Well. i put a Print("foo") in StringCharAt, and tried "foo"[0] and it doesn't get printed...
15:15:52  <caitp>ah, I see
15:16:17  <caitp>so the StringCharCodeAt operator gets used a bit in js-builtin-reducer, for inlining String.prototype.charCodeAt (and some other things)
15:16:27  <caitp>IIRC the string iterator inlining uses it too
15:26:03  <s1341>confusing...
15:39:34  <caitp>what are you researching exactly anyways?
15:39:49  <s1341>just trying to get a better feeling for how all this code works.
15:40:05  <s1341>specifically the new TurboFan stuff, and how it interacts with the older code.
15:41:09  <caitp>I see
15:41:58  <s1341>any pointers?
15:42:46  <caitp>well, the main path or the legacy full-codegen/crankshaft pipeline to get to turbofan is in ast-graph-builder.cc, afaik
15:43:46  <caitp>for*
15:54:56  * bradleymeckjoined
16:06:59  <s1341>Thanks. I'll look into that
16:17:46  <ilyaigpetrov>Today a bug crucial for me was fixed in v8. How long will it take before it lands in Chromium?
16:17:53  <ilyaigpetrov>this one: https://bugs.chromium.org/p/v8/issues/detail?id=5904
16:41:55  * RT|Chatzillaquit (Read error: Connection reset by peer)
18:02:31  * bradleymeckquit (Quit: bradleymeck)
18:10:35  * bradleymeckjoined
19:10:48  * xiinotulpjoined
19:11:21  * Guest59_joined
19:12:05  * Tweth-U-PDSjoined
19:13:06  * Guest59quit (Ping timeout: 240 seconds)
19:14:13  * plutoniixquit (Ping timeout: 240 seconds)
19:14:43  * Tweth-G-PDSquit (Ping timeout: 248 seconds)
19:18:40  * joyeejoined
19:24:11  * bradleymeckquit (Quit: bradleymeck)
19:28:07  * joyeequit (Remote host closed the connection)
19:37:10  * bradleymeckjoined
19:58:20  * Guest59_quit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:05:01  * Guest59joined
20:08:18  <jwolfe>i'm getting test failures when trying to ship trailing commas because test-parsing.cc initializes and runs the preparser without going through the parser like usual. there's code in test-parsing.cc to set up the flags, but trailing commas isn't one of the flags. it looks like the flags in the test are only for when you want to fiddle with the flags in the test, so i was thinking i would not add the flag there, but instead make the default value for
20:08:18  <jwolfe>allow_harmony_trailing_commas_(true) in the ParserBase() constructor. that makes the tests pass, but it'd be the only field with a non-zero default value. what should i do?
20:17:57  <jwolfe>oh, never mind. i see that that flag was already in test-parsing.cc before i started this CL. so leaving it alone probably makes the most sense.
20:45:20  * rwlbuis_quit (Quit: Connection closed for inactivity)
21:23:40  * joyeejoined
21:28:12  * joyeequit (Ping timeout: 245 seconds)
21:31:54  * ilyaigpetrovquit (Quit: Connection closed for inactivity)
22:07:22  * bradleymeckquit (Quit: bradleymeck)
22:08:36  * xiinotulpquit (Quit: Leaving)
22:38:01  <aklein>caitp: you around?
22:38:22  <caitp>aklein: pong
22:38:49  <aklein>caitp: so neis's suggestion was to use the try/catch/finally that wraps the entire async function
22:39:27  <aklein>and instead of rewriting return to resolve the promise, it'd be rewritten to save the return value somewhere, which the finally block would use to resolve the promise and then return
22:39:54  <caitp>and I think that doesn't really work
22:40:00  <caitp>or at least not cleanly
22:40:26  <caitp>it especially doesn't work with the stuff further down in the pipeline which is blocked on this, makes it all much more complicated with no real gain
22:40:47  <caitp>so, I don't think we really want to do that
22:41:36  <caitp>I am trying to split the refactoring apart from the fix, but I think it actually creates more review work rather than less
22:44:21  <caitp>basically, BG has a framework for fixing the problem already, and the AST desugaring gets in the way of that framework, I think the better fix is to just get rid of the AST desugaring rather than make it get in the way more
22:45:42  <aklein>what's the lack of cleanliness?
22:47:03  <aklein>from my point of view ( admittedly somewhat outside the implementation details), there's a bug in the existing code, and there's a straightforward-sounding fix. I'd rather fix the bug first and do the refactoring later, so as to get to a working state asap. but it sounds like the tricky part may be that it's not actually a "straightforward fix"
22:47:24  <caitp>well, it's a bug, but nobody else seems to have actually noticed the bug
22:47:50  <caitp>the ast fix is not very compatible with the work on async iteration so far, and I"d really like to not have to go back to the drawing board on it :p
22:48:11  <aklein>ah, ok, so that makes your objection clearer, thank you
22:49:17  <caitp>the patch as it is now does combine the jobs of fixing the bug and getting rid of the AST desugaring, and I think I can split it into 2 patches, but I don't think that's really easier to review, unfortunately
22:50:42  <aklein>is that because it's hard to get the "wrong" behavior with the refactored version?
22:57:03  <caitp>the ControlScope state machine seems to work pretty well
23:13:12  <aklein>caitp: I can buy that; I guess that's something to work out with littledan/neis, since they're the ones saying the current version is hard to review. I suspect the detailed CL description will help.
23:25:35  * Guest59quit (Ping timeout: 264 seconds)
23:27:28  * Guest59joined
23:36:33  * bradleymeckjoined
23:38:23  * RT|Chatzillajoined