00:01:48  <jmdyck>I agree it's the complete spec for how a parser (lexer) must handle whitespace, but I'm pretty sure that's not what adema is looking for.
00:03:24  <jmdyck>you could use what the spec says to define where whitespace is allowed/manadatory/forbidden, but it wouldn't be a very practical definition
00:06:50  <jmdyck>something like: whitespace is allowed at a given point in a source text if the insertion/deletion of whitespace at that point doesn't make a difference to the result of parsing the source text. If it does make a difference, then whitespace at that point is mandatory or forbidden or semantic, depending on how you define those.
00:39:19  * chicoxyzzyquit (Remote host closed the connection)
00:41:29  * chicoxyzzyjoined
00:45:44  * chicoxyzzyquit (Ping timeout: 246 seconds)
02:40:34  <TabAtkins>Same applies to CSS - except for a very small number of explicitly required/disallowed whitespace, the grammar is always just tokens, and whitespace is required only where you need it to make the tokens parse the way you want.
02:41:15  <TabAtkins>Excepting in calc() around the + and - operators, and in selectors when you want the descendant combinator, you never actually need whitespace in CSS - you can always replace it with an empty comment /**/.
02:43:23  * chicoxyzzyjoined
02:43:30  * caridyquit (Ping timeout: 255 seconds)
02:48:03  * chicoxyzzyquit (Ping timeout: 268 seconds)
03:41:55  * jmdyckquit (Quit: Leaving.)
04:44:49  * chicoxyzzyjoined
05:01:43  * chicoxyzzyquit (Ping timeout: 260 seconds)
06:58:31  * chicoxyzzyjoined
07:16:07  * chicoxyzzyquit (Ping timeout: 260 seconds)
07:27:27  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:13:00  * chicoxyzzyjoined
09:17:47  * chicoxyzzyquit (Ping timeout: 268 seconds)
09:55:20  * chicoxyzzyjoined
09:57:39  * chicoxyz_joined
10:00:20  * chicoxyzzyquit (Ping timeout: 268 seconds)
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
10:31:42  * chicoxyzzyjoined
10:35:24  * chicoxyz_quit (Ping timeout: 260 seconds)
11:40:56  * jmdyckjoined
11:55:04  * chicoxyzzyquit (Remote host closed the connection)
11:56:47  * chicoxyzzyjoined
14:54:54  * bradleymeckjoined
15:34:33  * not-an-aardvarkjoined
16:03:58  * bradleymeckquit (Quit: bradleymeck)
16:20:08  * bradleymeckjoined
17:33:00  * bradleymeckquit (Quit: bradleymeck)
17:36:37  * bradleymeckjoined
18:22:03  * gskachkovjoined
18:23:57  * gskachkovquit (Client Quit)
18:25:02  * gskachkovjoined
18:32:25  * caridyjoined
18:32:28  * caridyquit (Remote host closed the connection)
18:33:11  * caridyjoined
18:35:33  * gskachkovquit (Quit: gskachkov)
18:36:07  * gskachkovjoined
18:45:43  * gskachkovquit (Quit: gskachkov)
18:51:58  <rwaldron>caitp I believe I've found an excellent bug in V8 for-await
18:52:13  <caitp>is it the destructuring thing?
18:52:59  <rwaldron>The nitty gritty: destructuring bindings in for-await appear to _not_ evaluate the default value when the default value is `class Name {}`
18:53:15  <rwaldron>> <caitp> is it the destructuring thing?
18:53:17  <rwaldron>Maybe?
18:53:26  <caitp>sounds similar to the bug dan found
18:53:36  <caitp>which is a lot scarier than just "not evaluating"
18:53:44  <rwaldron>link?
18:55:06  <caitp>you probably can't access the chromium bugs, but it's pretty bbad
18:55:17  <rwaldron>> you probably can't access the chromium bugs
18:55:24  <rwaldron>seems silly, as a contractor :|
18:55:32  <rwaldron>aklein ping ^^
18:56:16  <caitp>https://chromium-review.googlesource.com/c/491686/8/test/mjsunit/harmony/regress/regress-6322.js << those are reproductions for it
18:56:20  <caitp>similar to what you've found?
18:56:28  <rwaldron>Let's find out
18:57:19  <rwaldron>WHOA
18:57:35  <rwaldron>The one I discovered does not dump like that
18:57:42  <rwaldron>the promise is just rejected
18:57:46  <caitp>interesting
18:57:47  <rwaldron>el-oh-el
18:57:57  <rwaldron>one sec
18:58:22  <caitp>I don't have a build with the patch applied, it would be interesting to see if it's fixed by the fix for the other thing, eg same bubg
18:58:27  <caitp>might bbe something different.
18:58:50  <rwaldron>(async function fn() {for await (const [cls = class {}, xCls = class X {}] of [[,,]]) {print(cls.name);print(xCls.name);}}()).then(_ => _, error => print(error.toString()));
18:59:15  <rwaldron>let me re-arrange it so that it's closer to Dan's
18:59:59  <caitp>it looks like it's probably the same bug, just manifesting in a less dangerous way (similar to how it manifests in normal for-of loops in generators)
19:00:36  <rwaldron>I think you're right about that
19:03:28  <caitp>btw, does v8 still fail the generated destructuring tests that you guys added recently that were apparently broken?
19:03:41  <caitp>I mean destructuring + for-await-of
19:03:56  * caridyquit (Remote host closed the connection)
19:04:10  <rwaldron>no it never did
19:04:24  * caridyjoined
19:04:51  <rwaldron>When I made the templates for "destructuring binding + for-await-of", I didn't think any of the cases had //- teardown
19:04:56  <rwaldron>turns out there were two cases
19:05:16  <rwaldron>2 * 6 templates = 12 failing cases you and cloudshu looked at
19:05:26  <rwaldron>I just finished the patch to correct that
19:05:39  <caitp>I saw, I was just wondering if we were passing the corrected tests
19:05:49  <rwaldron>yes, you are
19:05:53  <caitp>ok, thanks
19:05:54  <rwaldron>both runtimes
19:06:07  <rwaldron>The only issues now are related to the bug I mentioned above
19:06:26  <caitp>do you want to apply that CL and see if it fixes the case you tried?
19:06:38  <caitp>I can do it but I have some patches in progress, might take me a few days
19:07:03  <cloudshu>rwaldron: cool, SM too? thanks for fixing
19:07:15  <rwaldron>and not being able to use --harmony_object_rest_spread along with --harmony_async_iteration
19:07:22  <rwaldron>cloudshu yes, both
19:07:32  <rwaldron>that was always an accounting error on this end
19:07:34  <caitp>wait what?
19:07:52  <caitp>"not being able to use --harmony_object_rest_spread along with --harmony_async_iteration"
19:07:55  <rwaldron>Chock it up to my first set of tests back on the job
19:08:02  <rwaldron>caitp thats correct
19:08:13  <rwaldron>leobalter said you knew about that
19:08:23  <caitp>I don't think I'm familiar with this one
19:08:23  <leobalter>I reported that once
19:08:38  <leobalter>--harmony_async_iteration and --harmony
19:09:36  <caitp>sounds familiar but I don't recall the details
19:09:40  <leobalter>--harmony does not account for async_iteration neither object rest spread, I don't have a way on v8 for both at the same time
19:10:00  <rwaldron>When I try to use them at the same time, all the tests fail for either: "Expected no error, got SyntaxError: Unexpected reserved word" or " Expected no error, got SyntaxError: Unexpected token *"
19:10:41  <caitp>hm
19:10:47  <leobalter>nevermind
19:10:48  <leobalter>...
19:10:59  * leobalterruns `which d8` --harmony_async_iteration --harmony
19:11:13  <leobalter>looks like it does not work when I pass the args to test262-harness
19:11:27  <caitp>but it does work with other harmony flags?
19:11:35  <caitp>they should all work the same way
19:14:24  <rwaldron>Yep, I take that back
19:14:30  <rwaldron>It's definitely test262-harness
19:14:39  <rwaldron>sorry for the lies
19:15:53  <caitp>it's all good, trying to eliminate as many bugs with this thing as possible so it can ship some day
20:23:51  * dvaljoined
20:47:27  <adema>i read the clause and i understand your point about whitespaces being "ignored" but how do you recognize a valid token ? Everything between spaces are tokens ? What about "if(" ? Its not a valid one token sequence but its "if" and "(" tokens. On the other hand "vara=0" is never ok, it should always be separated by one or more tokens
20:47:56  <adema>one or more whitespaces sorry
20:49:50  <rwaldron>bterlson <3
21:19:21  <jmdyck>adema: re "how do you recognize a valid token?" The spec definitely answers that.
21:19:37  <jmdyck>That's what the lexical grammar is for.
21:22:08  <jmdyck>and it's not the case that "vara=0" is never ok: it's a valid assignment stmt.
21:23:10  <rwaldron>it's not valid in strict mode
21:23:36  <rwaldron>(but that's a ReferenceError)
21:24:09  <adema>well its valid but not in a "var a = 0;" sense
21:24:10  <rwaldron>(vs a SyntaxError)
21:34:35  <jmdyck>The InputElement* symbols are the goal symbols for the lexical grammar. They derive both tokens and non-tokens.
21:47:05  * dvalquit (Remote host closed the connection)
21:58:37  * chicoxyzzyquit (Remote host closed the connection)
22:00:42  * chicoxyz_joined
22:38:48  * caridyquit (Ping timeout: 240 seconds)
22:41:42  * chicoxyz_quit (Remote host closed the connection)
23:07:52  * bradleymeckquit (Quit: bradleymeck)