The assertOptimized approach seems like a good balance to me of:
1. Avoiding duplicating the assertion helpers and
2. Avoiding broadening d8's runtime environment
Then the only other requirement is that the usage of assertAsync (or
whatever it's called) in tests isn't affected by the concerns about
breaking the operating model assumptions.
On Tue, May 17, 2016 at 10:11 AM, Jakob Kummerow <jkumme...@chromium.org>
wrote:
> I agree that silent nops are bad, and that's not what we have: The
> implementation is
>
> try {
> OptimizationStatusImpl = new Function(
> "fun", "sync", "return %GetOptimizationStatus(fun, sync);");
> } catch (e) {
> throw new Error("natives syntax not allowed");
> }
>
> leading to:
>
> $ out/x64.release/d8 test/mjsunit/mjsunit.js -e "function f(){};
> assertUnoptimized(f);"
> test/mjsunit/mjsunit.js:436: Error: natives syntax not allowed
>
>
> throw new Error("natives syntax not allowed");
>
>
> ^
>
>
> Error: natives syntax not allowed
>
>
> at OptimizationStatus (test/mjsunit/mjsunit.js:436:15)
>
>
> at assertUnoptimized (test/mjsunit/mjsunit.js:444:16)
>
> The point is that mjsunit.js should still load without
> --allow-natives-syntax, so that not every test must specify that flag, only
> those tests that need to call %Natives.
>
> As I said, I don't know whether we need or should have any microtasks
> related helper(s) in mjsunit.js, I just wanted to point out that it's
> technically possible to use %Natives there.
>
> On Tue, May 17, 2016 at 6:29 PM, Michael Starzinger <
> mstarzin...@chromium.org> wrote:
>
>> On Tue, May 17, 2016 at 6:25 PM, Jakob Kummerow <jkumme...@chromium.org>
>> wrote:
>>
>>> On Tue, May 17, 2016 at 1:01 AM, Caitlin Potter <caitpotte...@gmail.com>
>>> wrote:
>>>
>>>> As part of the async functions runtime implementation, I had
>>>> implemented a function in d8.cc which would call isolate->RunMicrotasks()
>>>> --- but was talked down from doing this because of a worry that it might
>>>> interfere with certain uses of d8 out in the wild.
>>>>
>>>> So, I went with using the existing %RunMicrotasks runtime function ---
>>>> but of course this requires a flag to be present, so the mjsunit helpers
>>>> which rely on this can't be present in mjsunit.js (which means either a lot
>>>> of code duplication, or worse).
>>>>
>>>
>>> Yes they can; grep for "%GetOptimizationStatus" in mjsunit.js.
>>>
>>
>> I would vote for not adding yet another function like assertOptimized to
>> mjsunit.js that tries to catch the "SyntaxError: Unexpected token %" an
>> turns into a nop when the --allow-natives-syntax flag is not passed. This
>> just hides the fact that the request (i.e. draining the microtask queue)
>> can just not be fulfilled without said flag.
>>
>>
>>>
>>> (I can't comment on functionality concerns around %RunMicrotasks -- if
>>> the approach is invalid in general, then the above point is obviously moot.)
>>>
>>>
>>>> What I'd like to do is get a feel for just how dangerous something like
>>>> `runMicrotasks()` in d8.cc, or if we could get away with adding it as a
>>>> method of a `TestUtils` or `Utils` object instead. Something that would
>>>> allow tests which rely on being able to drain the microtask queue (in order
>>>> to execute quickly, predictably, and synchronously, while still verifying
>>>> the correct async behaviours), without requiring a --allow-natives-syntax
>>>> just to parse the script.
>>>>
>>>> I don't think there's a huge risk in adding these to d8.cc, and they
>>>> aren't exposed in v8 itself (or Chromium) --- if you're a user of d8 and
>>>> you think a global variable named "Utils", "TestUtils", "runMicrotasks", or
>>>> whatever, would interfere with your uses of d8, I'd like to hear why and
>>>> how.
>>>>
>>>> Hopefully, there's consensus that it's not dangerous to add such a
>>>> method or object to d8's global object.
>>>>
>>>> --
>>>> --
>>>> v8-users mailing list
>>>> v8-users@googlegroups.com
>>>> http://groups.google.com/group/v8-users
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "v8-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to v8-users+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-users@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to v8-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
