00:15:14  * bnoordhuisjoined
00:19:59  * bnoordhuisquit (Ping timeout: 264 seconds)
00:36:15  * caitp-joined
00:42:27  * enaqxjoined
01:56:47  * enaqxquit (Remote host closed the connection)
01:59:08  * enaqxjoined
04:08:21  * phpnode_quit (Ping timeout: 248 seconds)
04:21:21  * phpnode_joined
06:26:43  * muellijoined
06:31:23  * muelliquit (Ping timeout: 264 seconds)
06:34:21  * bnoordhuisjoined
06:43:28  * marja___quit (Ping timeout: 256 seconds)
06:55:30  * marja___joined
06:55:55  * mostynbjoined
07:00:40  * wingojoined
07:15:46  * caitp-quit (Ping timeout: 256 seconds)
07:21:36  * jwilmquit (Read error: Connection reset by peer)
07:42:46  * bnoordhuisquit (Ping timeout: 244 seconds)
07:43:32  * rendarjoined
07:59:46  * xiinotulpjoined
08:02:56  * plutoniixquit (Ping timeout: 240 seconds)
08:07:01  * caitp-joined
08:11:49  * caitp-quit (Ping timeout: 264 seconds)
08:18:27  * caitp-joined
08:28:33  * bnoordhuisjoined
08:36:46  * xiinotulpchanged nick to plutoniix
08:57:02  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Mozilla" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%202/builds/2376 "V8 Win32 - 2" from 1dbc43272954e8cfdf7be9a57c953a74b2a4d9da: wingo@igalia.com)
08:57:12  <wingo>d'oh
08:58:53  <wingo>why is this test a flake, i wonder
09:03:05  <trungl-bot>Tree opened by yangguo@chromium.org: Tree is open (will keep an eye on flakes)
09:16:01  * caitp-quit (Ping timeout: 264 seconds)
09:21:53  * enaqxquit (Remote host closed the connection)
09:26:54  * caitp-joined
09:28:57  * enaqxjoined
09:31:16  * caitp-quit (Ping timeout: 240 seconds)
11:01:06  * mostynbquit (Remote host closed the connection)
11:01:35  * mostynbjoined
11:12:31  * caitp-joined
11:18:25  * caitp-quit (Ping timeout: 264 seconds)
11:23:34  * caitp-joined
11:52:07  * mostynbquit (Ping timeout: 250 seconds)
11:53:24  * muellijoined
12:04:52  * mostynbjoined
12:05:07  * caitp-quit (Ping timeout: 250 seconds)
12:19:14  * enaqxquit (Ping timeout: 250 seconds)
12:46:38  * bradleymeckjoined
13:12:28  * mostynbquit (Ping timeout: 245 seconds)
13:25:47  * mostynbjoined
13:35:49  * bobmcw_changed nick to bobmcw
13:35:49  * bobmcwquit (Changing host)
13:35:49  * bobmcwjoined
13:46:46  * bradleymeckquit (Read error: Connection reset by peer)
13:48:45  * bradleymeckjoined
14:05:58  * mostynbquit (Quit: Leaving)
14:17:33  * caitp-joined
14:19:04  * jugglinmikejoined
14:20:36  * bnoordhuisquit (Ping timeout: 244 seconds)
14:22:03  * caitp-quit (Ping timeout: 245 seconds)
14:47:27  * bradleymeckquit (Read error: Connection reset by peer)
14:48:54  * bradleymeckjoined
14:55:40  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20-%202/builds/2891 "V8 Win32 - debug - 2" from c8e4d57d3b3036a05902f5b916cb5d853a57393c: dcarney@chromium.org,mvstanton@chromium.org)
15:12:56  * bradleymeckquit (Quit: bradleymeck)
15:18:41  * caitp-joined
15:19:55  * wingoquit (Remote host closed the connection)
15:22:28  * wingojoined
15:23:50  * caitp-quit (Ping timeout: 250 seconds)
15:27:32  * bnoordhuisjoined
15:31:25  * muelliquit (Ping timeout: 252 seconds)
15:32:04  * bnoordhuisquit (Ping timeout: 255 seconds)
15:36:01  <trungl-bot>Tree closed by machenbach@chromium.org: Tree is closed (looking into test failures)
15:38:19  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
15:44:07  * bnoordhuisjoined
15:45:18  * bobmcwquit
15:45:59  * bobmcwjoined
16:11:15  * bnoordhuisquit (Ping timeout: 265 seconds)
16:14:40  * BobGneuquit (Ping timeout: 256 seconds)
16:21:22  <trungl-bot>Tree opened by machenbach@chromium.org: Tree is open after speculative revert
16:23:20  * bradleymeckjoined
16:26:04  * bnoordhuisjoined
16:30:25  <caitp>arv / marja___ (if around) --- I'm not totally sure unifying parameter parsing in ParserBase works well now :l
16:30:48  <arv>caitp: Why not?
16:31:14  <caitp>it makes some assumptions about what formal parameters look like, and I don't think there's a way around those assumptions without making the preparser track more info
16:31:34  <caitp>which might be too expensive
16:32:38  <arv>what do you mean that it makes assumptions?
16:33:55  <caitp>right now the idea is that the formal parameters list is a set of names, which is fine --- the preparser can keep track of all the names it needs to care about easily --- but with destructuring, it really needs to track full AST nodes
16:35:02  <caitp>and in the preparser impl, you lose that info, so you end up with different behaviour between the two
16:35:13  <caitp>maybe I'm wrong but I don't think it works
16:38:21  <caitp>maybe I'm wrong, an expression list should be fine
16:38:38  <caitp>but needs some analog for GetBoundNames()
16:38:41  <arv>Even with destructuring params we can do the duplicate check as we go and do the eval/arguments/keyword check
16:39:17  <arv>The bound names are known as we parse, we do not need to hold on to them in the preparser
16:39:29  <caitp>they aren't really though
16:39:39  <arv>we know if it is a keyword
16:39:41  <caitp>when you parse an Object/Array pattern, you're not going to know
16:39:49  <arv>and we knows it is a duplicate
16:40:36  <arv>For destructuring bindings we do not need to use the array/object literal parser
16:40:55  <arv>Dmitry should be involved in this discussion
16:42:08  <arv>To make it clear. We should have dedicated parse functions for parseBindingPattern
16:42:25  <arv>it is only for BindingAssignment you need the cover grammaar
16:42:32  <caitp>that's fine, but you still need to be able to communicate the info back to ParseFormalParameters
16:43:07  <caitp>on a per binding basis
16:43:08  <arv>Agreed. The current list needs to contain an AST
16:46:22  <caitp>if you have a list of bound names (which may or may not be an actual list), an error location, and an expression list, and the index of a rest parameter, maybe that's enough info
16:47:58  <arv>Once you have destructuring in there you probably need to store an AST (unless we use some kind of syntactic sugar)
16:48:09  <arv>Not sure what the plan is there?
16:54:00  <caitp>well you need ast info for initializers, it probably makes sense for the rest of destructuring too
17:05:01  * davijoined
17:05:01  * daviquit (Changing host)
17:05:01  * davijoined
17:05:23  * muellijoined
17:06:43  <jugglinmike>arv: I'm having trouble figuring out the correct behavior of a certain statement in es6. Mind taking a look?
17:06:47  <jugglinmike>(function*() { var yield; yield; })().next();
17:07:35  <jugglinmike>in cases like that ^, does the environment record take precedence? Or does the syntax?
17:08:48  <jugglinmike>in other words, should that produce `{ result: undefined, done: false }` or `{ result: undefined, done: true }`?
17:08:51  <arv>A binding cannot be named yield inside a generator function
17:09:02  <arv>It should be a SyntaxError
17:09:18  <jugglinmike>Isn't that only the case in Strict mode?
17:09:41  <arv>I don't think so
17:09:46  * ofrobotsjoined
17:09:47  <jugglinmike>the same way that `(function() { var let; })` is valid?
17:10:02  <arv>gtg... I can dig into the spec a bit when I come back
17:10:47  <jugglinmike>thanks--I'll keep looking in the mean time
17:14:26  <caitp>i'm reading it, and it looks to me like you can declare a variable named "yield" in non-strict code
17:14:33  <caitp>which seems like it's probably a spec bug
17:16:27  <caitp>you know what
17:16:32  <caitp>I might be wrong
17:17:00  <jugglinmike>caitp: yeah, it's only FutureReserved in strict mode
17:17:11  <jugglinmike>If there were to be a restriction on `yield` that was specific to generator function bodies (strict or otherwise), I think it would be here https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions-static-semantics-early-errors
17:17:38  <caitp>it's hard to read the parameterization rules
17:17:45  <caitp>but it looks like it might be disallowed by parameterization
17:18:52  <jugglinmike>wouldn't that be denoted on the GeneratorBody references themselves?
17:19:43  <caitp>BindingIdentifier[Yield]: Identifier [~Yield] yield
17:20:13  <caitp>should mean that "yield" can only be a BindingIdentifier if the [YIeld] parameterization is "off"
17:20:33  <caitp>the notation is really hard to read so it's possible I'm wrong, but that's what it looks like to me
17:20:52  <jugglinmike>I've been tripped up by these more than a few times
17:22:26  <jugglinmike>caitp: Rick just pointed me to https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions
17:22:42  <jugglinmike>GeneratorBody : FunctionBody[Yield]
17:23:04  <caitp>yes, which is why VariableStatements within the GeneratorBody should not be able to use "yield" as a BindingIdentifier
17:23:08  <caitp>if I'm reading it right :p
17:24:30  <jugglinmike>If a right-hand side alternative is prefixed with “[+parameter]” that alternative is only available if the named parameter was used in referencing the production’s nonterminal symbol. If a right-hand side alternative is prefixed with “[~parameter]” that alternative is only available if the named parameter was not used in referencing the production’s nonterminal symbol.
17:24:39  <jugglinmike>caitp: I think you are
17:26:15  <jugglinmike>thanks for the help!
17:26:22  <caitp>shur
17:29:15  * mostynbjoined
17:41:13  * muelliquit (Ping timeout: 245 seconds)
17:44:58  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:05:52  * caitp-joined
18:08:03  * ofrobotsjoined
18:11:02  * caitp-quit (Ping timeout: 244 seconds)
18:43:46  * bradleymeckquit (Quit: bradleymeck)
18:48:08  * bradleymeckjoined
18:49:32  * muellijoined
18:53:08  * srl295quit (Ping timeout: 250 seconds)
18:53:57  * srl295joined
18:53:57  * srl295quit (Changing host)
18:53:57  * srl295joined
19:05:02  * daviquit (Ping timeout: 246 seconds)
19:13:21  * jonaslundjoined
19:13:24  * jonaslundpart
19:21:09  * caitp-joined
19:27:44  <jugglinmike>caitp- caitp Do you know why it is written as `Identifier [~Yield] yield` and not `Identifier [+Yield] yield` ? It seems like if it were written with `+`, the productions would be more intuitive--the "[Yield]" subscript parameter would then mean, "`yield` *is* valid in this production". Of course, I may have just confused myself again
19:30:14  <arv>I also find the parameter notation overly confusing... maybe this annotation is common in cs though?
19:30:58  <caitp->i haven't really seen it in any other bnf-ish grammar
19:31:32  <caitp->i guess yacc has some similar concepts with states though
19:31:36  <caitp->but not really
19:33:08  <jugglinmike>I couldn't say :/
19:34:24  * bnoordhuisquit (Ping timeout: 245 seconds)
19:38:58  <bradleymeck>im not sure https://code.google.com/p/v8/issues/detail?id=3133&q=generator&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified should be an issue given the spec test I linked
19:39:46  <jugglinmike>alternatively, `Identifier [~NoYield] yield`
19:40:07  * mostynbquit (Quit: Leaving)
19:40:09  <jugglinmike>then just find-and-replace `[Yield]` with `[NoYield]`
19:42:11  <caitp->haven't you heard, default-deny is better than default-permit
19:46:11  * rendarquit (Ping timeout: 250 seconds)
19:51:47  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:52:59  * rendarjoined
19:54:42  * bradleymeckquit (Quit: bradleymeck)
20:05:35  * wingoquit (Ping timeout: 246 seconds)
20:08:51  * enaqxjoined
20:15:46  * ofrobotsjoined
20:20:10  * wingojoined
20:26:43  * bradleymeckjoined
20:35:32  * enaqxquit (Remote host closed the connection)
20:40:34  * bnoordhuisjoined
20:41:59  * enaqxjoined
20:43:25  * enaqxquit (Remote host closed the connection)
20:45:04  * enaqxjoined
20:52:23  * enaqxquit (Remote host closed the connection)
21:01:24  * plutoniixquit (Ping timeout: 272 seconds)
21:05:21  * enaqxjoined
21:05:58  * enaqxquit (Remote host closed the connection)
21:06:12  * enaqxjoined
21:28:47  * plutoniixjoined
21:35:44  * bradleymeckquit (Quit: bradleymeck)
21:50:23  * muelliquit (Ping timeout: 245 seconds)
21:52:48  * rendarquit
21:59:15  * wingoquit (Ping timeout: 265 seconds)
22:19:12  * RT|Chatzillajoined
22:19:50  * bnoordhuisquit (Ping timeout: 250 seconds)
22:24:43  * jugglinmikequit (Ping timeout: 255 seconds)
22:43:04  * bradleymeckjoined
22:49:27  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:50:14  * ofrobotsjoined
22:50:59  * ofrobotsquit (Client Quit)
22:59:44  * bradleymeckquit (Quit: bradleymeck)
23:02:31  * ofrobotsjoined
23:03:41  * ofrobotsquit (Client Quit)
23:05:01  * ofrobotsjoined
23:07:01  * ofrobotsquit (Client Quit)
23:23:12  * ofrobotsjoined
23:24:05  * ofrobotsquit (Client Quit)
23:26:16  * bradleymeckjoined
23:26:30  * bnoordhuisjoined
23:31:02  * bnoordhuisquit (Ping timeout: 246 seconds)
23:37:03  * ofrobotsjoined
23:56:47  * ph0dderchanged nick to erichanson