03:03:26  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
03:21:23  * RT|Chatzillajoined
08:04:09  * xaxxonjoined
08:04:40  <xaxxon>is FunctionTemplate::Inherit how you set up the inheritance hierarchy for objects created with "new SomeFunction()"?
08:18:41  * xiinotulpjoined
08:22:25  * plutoniixquit (Ping timeout: 258 seconds)
08:23:28  * sin8hjoined
09:11:40  * sin8hquit (Quit: Leaving.)
10:02:27  * sin8hjoined
10:03:48  * sin8hquit (Client Quit)
10:12:32  * sin8hjoined
10:25:07  * sin8hquit (Quit: Leaving.)
10:25:49  * sin8hjoined
10:35:43  * sin8hquit (Quit: Leaving.)
10:46:15  * sin8hjoined
10:46:28  * sin8hquit (Client Quit)
10:54:33  * koldbrutalityquit (Ping timeout: 240 seconds)
10:55:50  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Ignition - turbofan" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10355 "V8 Linux - arm64 - sim - MSAN" from c13acc815388aff94a5694ae9ad2587fa3cf42b2: [email protected])
10:55:59  * koldbrutalityjoined
11:01:00  <xaxxon>figured out what I was doing wrong, btw... nothing to do with Inherit
11:01:01  * xaxxonpart
11:01:53  <trungl-bot>Tree opened by [email protected]: Tree is open (Fix on the way)
11:17:19  * clinthquit (Ping timeout: 250 seconds)
11:20:14  * clinthjoined
11:28:11  * clinthquit (Ping timeout: 244 seconds)
11:31:42  * clinthjoined
13:20:40  * bradleymeckjoined
13:21:11  * bobmcwjoined
14:26:49  * bradleymeckquit (Quit: bradleymeck)
14:54:20  * bradleymeckjoined
15:16:08  <trungl-bot>Tree opened by [email protected]: Tree is open
15:17:28  * ofrobots_ooochanged nick to ofrobots
15:22:07  * kenansulaymanjoined
15:22:30  * kenansulaymanchanged nick to Guest26216
15:24:09  * Guest26216quit (Changing host)
15:24:09  * Guest26216joined
16:04:35  * caitpquit (Ping timeout: 240 seconds)
16:07:33  * clinthquit (Ping timeout: 240 seconds)
16:11:09  * caitpjoined
16:13:04  * clinthjoined
16:33:41  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
16:52:18  * seventhjoined
16:55:40  * Guest10485quit (Ping timeout: 264 seconds)
16:56:43  * s1wjoined
16:57:05  * s1wchanged nick to Guest49323
17:28:59  * jgijoined
17:36:06  * trevnorr1schanged nick to trevnorris
18:27:43  <caitp>hello #v8
18:27:51  <caitp>hows it goin
18:27:55  <caitp>cool
18:42:48  * jgiquit (Quit: jgi)
18:49:13  * jgijoined
18:57:25  * jgiquit (Quit: jgi)
18:58:23  <aklein>caitp: hi :)
18:59:08  <caitp>hey
18:59:33  <caitp>the reason those extra stack overflow checks were added in dan's desugaring CL, was a regression test that started failing again, iirc
19:00:00  <caitp>I guess adding those checks in the compiler was a simpler fix or something?
19:00:57  <caitp>I think it's about https://cs.chromium.org/chromium/src/v8/test/mjsunit/harmony/regress/regress-624300.js?l=11
19:01:11  * bnoordhuisjoined
19:02:12  <caitp>ah, he just explained the fix. pretty sure that's the test that broke, but it makes sense now at least
19:04:09  * bnoordhuisquit (Client Quit)
19:07:21  * jgijoined
19:07:31  * jgiquit (Client Quit)
19:20:07  <aklein>caitp: yeah, I see this while loop now
20:28:27  * seventhquit (Ping timeout: 258 seconds)
20:52:44  * seventhjoined
21:06:06  * bobmcwquit (Remote host closed the connection)
21:25:06  * bradleymeckquit (Quit: bradleymeck)
22:04:32  * seventhquit (Ping timeout: 240 seconds)
22:29:56  <aklein>caitp: do you recall why you went with this CheckDestructuringElement() approach to error-checking in destructuring assignment instead of changing BindingPatternError to PatternError in all the places where something's disallowed?
22:30:46  <caitp>it was there already
22:30:47  <aklein>it seems odd to me that 'var {y: ++x} = {}' and '({y: ++x} = {})' get their errors detected at totally different places
22:32:38  <aklein>caitp: afaict CheckDestructuringElement() was created in https://codereview.chromium.org/1309813007
22:32:57  <caitp>it was based on stuff that was already in the tree
22:33:27  <caitp>the approach dudnt originate there
22:34:39  <aklein>oh heh, and the blamelist shows that I was the one that left CheckDestructuringElement as it is...
22:36:46  <caitp>also, not clear how they could happen in the same place
22:37:13  <caitp>since when you parse it, it doesnt look like an assignment target
22:37:44  <caitp>and its unknown if its a pattern or not
22:38:38  <aklein>well CheckDestructuringElement just records a bit in the expression classifier, it doesn't assume it knows that it's dealing with a pattern
22:40:02  <caitp>that sounds diff from the original version
22:40:29  <aklein>maybe you're thinking of a different function?
22:40:36  <aklein>this one has always been about poking the classifier
22:57:13  <caitp>poking it as in recording errors?
22:57:32  <caitp>because thats what I remember writing
22:58:06  <caitp>there was no bit to set other than at one point recording if
22:58:30  <caitp>cover-initialized-name occurred, but was removed before landing
23:16:44  * RT|Chatzillajoined