00:10:09  * plutoniixquit (Quit: Leaving)
00:34:35  * xaxxonquit (Quit: xaxxon)
02:19:03  * plutoniixjoined
02:41:00  * RT|Chatzillaquit (Ping timeout: 276 seconds)
03:00:23  * RT|Chatzillajoined
03:56:25  * bradleymeckquit (Read error: Connection reset by peer)
03:58:18  * bradleymeckjoined
04:26:16  * bradleymeckquit (Read error: Connection reset by peer)
04:29:05  * bradleymeckjoined
06:49:12  * plutoniixquit (Remote host closed the connection)
10:06:53  * hferreirojoined
10:24:14  * Keverwquit (Read error: Connection reset by peer)
10:29:44  * hferreiroquit (Remote host closed the connection)
12:33:04  * seventhjoined
12:34:54  * bradleymeckquit (Quit: bradleymeck)
13:07:39  * bradleymeckjoined
13:44:16  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "gclient runhooks" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug%20builder/builds/16014 "V8 Linux - debug builder" from 20a8ef0b92604d65f7d2d27be406245588d18b22: jbroman@chromium.org)
13:53:56  * bradleymeckquit (Quit: bradleymeck)
13:54:26  * RT|Chatzillaquit (Read error: Connection reset by peer)
13:59:48  * RT|Chatzillajoined
14:26:47  * bradleymeckjoined
14:38:07  * seventhquit (Ping timeout: 244 seconds)
14:59:41  * plutoniixjoined
15:10:49  * bradleymeckquit (Quit: bradleymeck)
15:24:03  <trungl-bot>Tree opened by vogelheim@chromium.org: Tree is open (looks like a fluke; not really sure, though)
15:42:18  * bradleymeckjoined
15:42:35  * bradleymeckpart
15:46:12  <trungl-bot>Tree opened by vogelheim@chromium.org: Tree is open (oooooopen)
15:53:16  * bobmcwjoined
16:25:09  * seventhjoined
16:27:21  * cslcmquit
16:29:15  * thefourtheyejoined
16:29:46  * bradleymeckjoined
16:43:16  * RT|Chatzillaquit (Read error: Connection reset by peer)
17:13:06  * bradleymeckquit (Quit: bradleymeck)
18:57:13  * seventhquit (Quit: ...)
19:03:11  * bradleymeckjoined
19:16:38  <dherman>what does oilpan mean for the future of the rooting/handle API?
19:56:15  <aklein>dherman: hard to see the future...I can't imagine we'd want to require embedders to have a traceable heap though :)
19:57:26  <dherman>aklein: I can see that. it might be good to be able to enable embedders to if they want to though
19:57:45  <dherman>btw I'm curious if you have thoughts about my API request
19:57:48  <aklein>seems reasonable
19:58:10  <dherman>any advice on how to move it forward?
19:58:26  <dherman>I'm happy to Do The Work
20:00:24  <aklein>it did get triaged correctly to the right folks...August can just be a fairly slow month as many folks are on vacation
20:01:13  <dherman>np
20:01:41  <aklein>CCed a few more people
20:02:09  <aklein>cbruni@ in particular is our current ElementsAccessor expert
20:02:20  <aklein>and has been looking a lot at what makes using the API slow
20:02:33  <caitp>jakob seems pretty knowledgable about it as well
20:03:02  <aklein>yeah
20:03:16  <dherman>thx!
20:03:27  <aklein>as for Doing The Work, I think I'd like to get someone to say "yes that's a good idea" before suggesting you go write code...
20:03:34  <dherman>oh absolutely
20:03:36  <dherman>that's why I ask
20:03:46  <dherman>and I also include "flesh out more of the design" amongst "The Work"
20:03:56  <dherman>basically I'm looking to help but I'm not going to run ahead of consensus
20:10:03  <aklein>sounds about right, hopefully we can get you some initial feedback
20:10:20  <aklein>(my initial feedback is that it seems reasonable but that particular code isn't my usual responsibility :)
20:13:07  <dherman>kk! and thanks for the help!
20:22:03  <dherman>ok I have a probably dumb question
20:22:27  <dherman>actually nvm
20:51:52  * bobmcwquit (Remote host closed the connection)
21:07:04  * bradleymeckquit (Quit: bradleymeck)
21:56:03  * koldbrutalityquit (Ping timeout: 240 seconds)
21:58:36  * bradleymeckjoined
22:05:09  * koldbrutalityjoined
22:09:33  * koldbrutalityquit (Ping timeout: 240 seconds)
22:12:36  * koldbrutalityjoined
22:14:46  <aklein>caitp: if you're around, I'm curious if you know why this line exists: https://cs.chromium.org/chromium/src/v8/src/parsing/parser-base.h?rcl=0&l=2787
22:17:47  <caitp>to ban an arrow function with `await` as a formal parameter defined within an async function, afaik
22:18:18  <aklein>that's what the third line down does, I think
22:18:26  <aklein>I removed the ExpressionError line and no tests fail...
22:18:35  <aklein>hmm, let's run test262
22:19:00  <caitp>feel free to remove it if tests pass
22:19:16  <aklein>k, the "just in case" made me immediately suspicious of it
22:23:12  <aklein>another related question, is there a reason that AsyncBindingPatternProduction is separate from BindingPatternProduction?
22:23:21  <aklein>similar question for AsyncArrowFormalParameters
22:23:25  <aklein>caitp: ^
22:24:01  <caitp>well, within an async function, you do always need an operand for await, so }, ) and ], and , would all mean not operands
22:24:15  <aklein>hmm, ok, trying to wrap my head around this
22:27:29  <caitp>the thing on line 3 actually looks wrong, since the AsyncArrowFormalParameters error should be recorded in ParseAndClassifyIdentifier or w/e it's called
22:27:41  <caitp>should just be a plain arrow function error, afaik
22:28:22  <caitp>iirc `async function() { var f = (await) => await; }` is illegal, similar to `function* g() { var f = (yield) => yield; }` is illegal
22:28:34  <caitp>but I would ask bterlson for clarification
22:28:35  <aklein>I was _just_ about to ask that
22:28:38  <aklein>to bterlson
22:28:47  <aklein>because it seems weird to not follow what we did for yield
22:31:17  <aklein>our parsing tests test that it works
22:31:41  <caitp>hmm
22:31:46  <caitp>I think I did ask him before but I can't remember
22:35:21  <caitp>I think we can get rid of the UnexpectedToken thing, but probably need to change the classifier error to an ArrowFunction error
22:35:59  <caitp>and fix tests if the tests are just wrong
22:38:11  <aklein>k, working on it...
22:38:22  <caitp>I can't actually find tests in test-parsing.cc that involve the normal arrow function with the `await` keyword
22:38:44  * bradleymeckquit (Quit: bradleymeck)
22:39:46  <aklein>caitp: I found 1
22:39:51  <aklein>search for "(await) =>"
22:40:29  <caitp>only instance I see is an async arrow function
22:40:52  <caitp>none with the plain non-async arrow
22:43:03  <caitp>`async function f() { var x = (await) => 1; }` is not a SyntaxError in Canary, so I'm pretty sure the bug is that line recording the wrong type of error
22:43:35  <aklein>yes, it is
22:43:40  <aklein>https://cs.chromium.org/chromium/src/v8/test/cctest/test-parsing.cc?q=%5C(await%5C)%5C+%3D%3E&sq=package:chromium&l=7755&dr=C
22:43:43  <aklein>that's the test
22:44:18  <aklein>there's other weird stuff here
22:44:24  <caitp>ah I see. that's testing that it's not an error, though
22:44:29  <aklein>right :)
22:44:31  <caitp>so yeah, bad test
22:45:33  <aklein>fix coming up
22:45:35  <caitp>what other weird stuff? those other things all look pretty normal
22:46:02  <aklein>hmm, actually, no, ignore the "other weird stuff" thing
22:54:44  <aklein>looks like we don't need AsyncBindingPatternProduction as its own category in ExpressionClassifier
22:54:58  <aklein>though it sounds like we do need AsyncArrowFormalParametersProduction?
22:55:57  <caitp>I believe we do need AsyncArrowFormalParametersProduction to ban `await`. I believe the BindingPattern thing was for banning `await` in var { ... } declarations
22:56:55  <caitp>some of that stuff also probably helps ban it in `var [ ... ]` too, not sure. the recursive decent parser has become a bit hard to follow.
22:58:51  <aklein>yeah
22:59:07  <aklein>we may finally be getting rewindable token stream, some day!
23:08:41  <aklein>just happened to find this stuff when trying to answer questions gsathya was posing...
23:11:46  <caitp>I posted on that to give you background on it.
23:12:04  <caitp>unfortunately, rietveld posted a double comment, so sorry about the extra email
23:12:43  * dhermanquit (Ping timeout: 244 seconds)
23:12:45  * oleavrquit (Ping timeout: 276 seconds)
23:13:04  * littledan__quit (Ping timeout: 264 seconds)
23:13:15  * littledan__joined
23:13:58  <aklein>oh dear
23:14:06  <aklein>that RecordExpressionError is very much required
23:14:10  <aklein>we just have to test coverage for it
23:15:56  <caitp>what breaks without it?
23:16:05  * dhermanjoined
23:16:17  <aklein>async function foo() { return (await) }
23:16:21  <aklein>isn't reported as an error
23:16:22  <caitp>ah
23:19:02  <aklein>ooo, and I found another bug!
23:19:23  * oleavrjoined
23:19:31  <aklein>async function foo() { return {await} }
23:19:32  <aklein>sigh
23:19:41  <aklein>this parser is hard to maintain
23:20:45  <caitp>well, if any of those tokens are found following an `await` in an async function, I think it's valid to just instantly SyntaxError, and not involve the classifier
23:20:51  <caitp>since the operand is not optional in async funcitons
23:21:02  <aklein>yeah it's the structure of this code that's leading to those errors
23:22:20  <caitp>it was probably all written that way to make `await` legal in arrow formal params inside an async function, so the classifier stuff there is probably not needed at all anymore
23:22:23  * RT|Chatzillajoined
23:23:00  <aklein>yeah that's the definite feeling I'm getting :)
23:23:18  <aklein>let's try deleting it and see what we get
23:25:15  <caitp>well, delete and replace with `ReportMessageAt()`
23:25:55  <caitp>i guess the only issue is not knowing if it's a "bad formal parameters" message or a "bad expression" message
23:26:35  <caitp>personally, I'm fine with reporting a less understandable message if it means getting rid of more uses of the classifier
23:31:26  * thefourtheyequit (Quit: Connection closed for inactivity)
23:33:13  <aklein>I can just delete, it causes ParseUnaryExpression() to choke on an RPAREN, COMMA, etc
23:33:44  <aklein>that is, the error is that your await expression is malformed, not that you tried to use 'await' as an identifier
23:33:59  <aklein>actually I'm not sure about the "{await}" case now
23:34:11  <aklein>does object literal shorthand have any special rules?
23:35:02  <caitp>what do you mean by special?
23:35:40  <aklein>well, {await: 42} is clearly valid
23:35:46  <caitp>`BindingIdentifier Initializer(opt)`
23:36:23  <caitp>you can't declare a variable named await, so `var {await} = {}` would be an error
23:36:36  <caitp>as would `var {await = 10}`
23:36:39  <aklein>you can outside the function
23:36:48  <aklein>I'm not talking about destructuring
23:36:51  <aklein>this is for an object litearl
23:37:05  <aklein>ok, the shorthand is an IdentifierReference
23:37:14  <aklein>whee
23:39:03  <caitp>what is the difference between IdentifierReference and BindingIdentifier?
23:39:10  <caitp>their productions look identical
23:40:30  <aklein>the difference I was talking about is between PropertyName and IdentifierReference
23:41:05  <caitp>oh, yes, you can't have { "foo" = 1 } or { [foo] = 1 }
23:41:42  <aklein>we're still talking about different things...
23:43:05  <caitp>"yield" restrictions (and "await" restrictions) still apply to IdentifierReferences, not to PropertyNames
23:43:10  <aklein>right
23:43:17  <aklein>I think we actually get this wrong in a variety of ways
23:43:29  <aklein>"{eval}" is treated as a valid object literal in strict code
23:43:34  <caitp>would not surprise me
23:43:43  <aklein>whee off to file a bug
23:43:54  <aklein>kinda shocked there aren't test262 tests for this
23:44:42  <caitp>it looks like that particular rule only applies to BindingIdentifier?
23:44:55  <caitp>at least, in 12.1.1
23:45:05  <caitp>I'm sure it comes up again somewhere
23:45:22  <caitp>IsValidSimpleAssignmentTarget, ok
23:46:16  <caitp>anyways, I"m gonna walk away from this for now, ping me if any of my parser code is weird or something
23:46:38  <aklein>have a good weekend
23:46:44  <aklein>it's too late on friday to be worried about this stuff
23:47:09  <aklein>oh, yeah
23:47:10  <aklein>ok
23:47:19  <aklein>yield is just special for other reasons