[inspector] extend protocol for code coverage.

[inspector] extend protocol for code coverage.

R=jgruber@chromium.org, kozyatinskiy@chromium.org, pfeldman@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2700743002
Cr-Commit-Position: refs/heads/master@{#43363}
Committed: https://chromium.googlesource.com/v8/v8/+/901c29eb1c5783e72b8926f0a1b0d9e13b69f3c0

[Yang, 2017-02-16 09:02:29]

The CQ bit was checked by yangguo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 09:02:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jgruber, 2017-02-16 09:42:35]

lgtm

https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.json
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.j...
src/inspector/js_protocol.json:382: "parameters": [],
Can we remove empty parameters?

[Yang, 2017-02-16 09:51:13]

https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.json
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.j...
src/inspector/js_protocol.json:382: "parameters": [],
On 2017/02/16 09:42:35, jgruber wrote:
> Can we remove empty parameters?

Good point.

[Yang, 2017-02-16 09:51:18]

The CQ bit was checked by yangguo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 09:51:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-16 10:18:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-16 10:18:12]

Dry run: Try jobs failed on following builders:
  v8_linux_chromium_gn_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_chromium_gn_rel/bu...)

[Yang, 2017-02-16 11:41:32]

On 2017/02/16 09:51:13, Yang wrote:
>
https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.json
> File src/inspector/js_protocol.json (right):
> 
>
https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.j...
> src/inspector/js_protocol.json:382: "parameters": [],
> On 2017/02/16 09:42:35, jgruber wrote:
> > Can we remove empty parameters?
> 
> Good point.

For Chrome to build, I found that I have to patch
src/content/browser/devtools/protocol_config.json to add the two new types. Is
there any way I can do it without having it to sync it with a V8 roll?

[Yang, 2017-02-16 12:39:40]

On 2017/02/16 11:41:32, Yang wrote:
> On 2017/02/16 09:51:13, Yang wrote:
> >
>
https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.json
> > File src/inspector/js_protocol.json (right):
> > 
> >
>
https://codereview.chromium.org/2700743002/diff/1/src/inspector/js_protocol.j...
> > src/inspector/js_protocol.json:382: "parameters": [],
> > On 2017/02/16 09:42:35, jgruber wrote:
> > > Can we remove empty parameters?
> > 
> > Good point.
> 
> For Chrome to build, I found that I have to patch
> src/content/browser/devtools/protocol_config.json to add the two new types. Is
> there any way I can do it without having it to sync it with a V8 roll?

I just figured out that you can add types to protocol_config.json that are not
yet defined, so we can do that change upfront:
https://codereview.chromium.org/2699863002/

[kozy, 2017-02-16 16:47:19]

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:377: "description": "Disable precise code
coverage. Disabling releases unnecessary execution count records and allows
executing optimized code.",
Does this method reset counters?

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
File src/inspector/v8-runtime-agent-impl.cc (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:650:
v8::debug::Coverage::TogglePrecise(m_inspector->isolate(), true);
We can be prepared for more then one runtime agent (bright future with multi
client support) and implement togglePrecise on V8Debugger and store counter
there. Like we do for enable/disable [1].

[1]
https://cs.chromium.org/chromium/src/v8/src/inspector/v8-debugger.cc?rcl=6346...

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:655:
v8::debug::Coverage::TogglePrecise(m_inspector->isolate(), false);
- please toggle precise off in V8RuntimeAgentImpl::disable,
- and we need to support provisional precise coverage on page reload - it means
that you need to store precise state in m_state, e.g.
customObjectFormatterEnabled, and restore it in V8RuntimeAgentImpl::restore.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:660:
std::unique_ptr<protocol::Runtime::CoverageRange> CreateCoverageRange(
We still use not V8 code style here, let's don't mix code styles until we move
everything to new one - createCoverageRange.

https://codereview.chromium.org/2700743002/diff/40001/test/inspector/runtime/...
File test/inspector/runtime/coverage.js (right):

https://codereview.chromium.org/2700743002/diff/40001/test/inspector/runtime/...
test/inspector/runtime/coverage.js:23: .then(() =>
Protocol.Runtime.compileScript({ expression: source, sourceURL: url,
persistScript: true }))
You can just add //# sourceURL=fib.js to your source string and use
Protocol.Runtime.evaluate({ expression: source }) instead of compile/run Script.

[kozy, 2017-02-16 18:17:50]

On 2017/02/16 12:39:40, Yang wrote:
> I just figured out that you can add types to protocol_config.json that are not
> yet defined, so we can do that change upfront:
> https://codereview.chromium.org/2699863002/

It was a bug. You don't need to add a Runtime type into browser
protocol_config.json if it's not used by browser_protocol.
Fix: https://codereview.chromium.org/2705443002/

[pfeldman, 2017-02-16 21:23:10]

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:211: "properties": [
experimental: true

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:212: { "name": "functionName", "type": "string",
"description": "JavaScript function name." },
Make it optional: not all of the ranges will have associated function names in
the future.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:217: { "name": "nested", "type": "array",
"items": { "$ref": "CoverageRange" }, "description": "Nested inner coverage
ranges." },
I'd drop this.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
I'd just flatten array of ranges.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:376: "name": "stopPreciseCoverage",
How do I get a result?

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:385: "description": "Collect coverage data for
the current isolate.",
We should not expose non-precise coverage, while this could pull the coverage
data.

[Yang, 2017-02-16 21:30:51]

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
On 2017/02/16 21:23:09, pfeldman wrote:
> I'd just flatten array of ranges.

Wouldn't you have to reconstruct the nesting on the frontend?

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:376: "name": "stopPreciseCoverage",
On 2017/02/16 21:23:09, pfeldman wrote:
> How do I get a result?

By calling collectCoverage.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:377: "description": "Disable precise code
coverage. Disabling releases unnecessary execution count records and allows
executing optimized code.",
On 2017/02/16 16:47:19, kozy wrote:
> Does this method reset counters?

No. Starting resets counters.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:385: "description": "Collect coverage data for
the current isolate.",
On 2017/02/16 21:23:09, pfeldman wrote:
> We should not expose non-precise coverage, while this could pull the coverage
> data.

Fadi wanted exactly that though. He does not care about false negatives, but
affecting performance would be a no go.

[pfeldman, 2017-02-16 23:04:51]

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
> Wouldn't you have to reconstruct the nesting on the frontend?

We might be implying different nesting. If we are talking nested functions, then
no, we don't need nesting in the front-end. But if we are talking about
statement-level ranges within the function, then yes, we need one level nesting.
In other words, we could have 

{ scriptId: id,
  functions: [
    { functionName, functionRange, ranges: [{from, to, count}] }
  ]
}

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:381: "name": "collectCoverage",
Does it reset counters? I would expect both stopPreciseCoverage and
collectCoverage to reset counters. I'd also rename collectCoverage to
takeCoverage.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:385: "description": "Collect coverage data for
the current isolate.",
> Fadi wanted exactly that though. He does not care about false negatives, but
> affecting performance would be a no go.

We need to split best effort and precise coverage accessors then. Precise should
be started, stopped and polled. Best effort could be just queries. In fact, I'd
like to learn more about the best effort data - is it even good?

[pfeldman, 2017-02-16 23:13:42]

Briefly talked to Fadi - he is suggesting the data is pretty good, so it makes
sense exposing it. I still think we should use two different methods for these.
Fetching precise would reset counters, fetching best-effort will just return
current state of the world. Does it make sense?

[Yang, 2017-02-17 05:35:54]

Will address these issues by Monday. Adding Fadi on CC regarding whether to
reset counters.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
On 2017/02/16 23:04:51, pfeldman wrote:
> > Wouldn't you have to reconstruct the nesting on the frontend?
> 
> We might be implying different nesting. If we are talking nested functions,
then
> no, we don't need nesting in the front-end. But if we are talking about
> statement-level ranges within the function, then yes, we need one level
nesting.
> In other words, we could have 
> 
> { scriptId: id,
>   functions: [
>     { functionName, functionRange, ranges: [{from, to, count}] }
>   ]
> }

In that case I suggest introducing a new type for inner ranges inside the
function for future statement-level coverage, once we have that, since these
ranges do not have function name associated. The functionName field would also
become non-optional.

But how come you don't care about nesting? Inner functions split the range of
its outer function, so you would have different counts associated with the
source positions in a function depending on whether it overlaps with an inner
function or not. Is that not necessary for the UI?

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:381: "name": "collectCoverage",
On 2017/02/16 23:04:51, pfeldman wrote:
> Does it reset counters? I would expect both stopPreciseCoverage and
> collectCoverage to reset counters. I'd also rename collectCoverage to
> takeCoverage.

So you want incremental counts from last time coverage is taken? You'd need a
copy of the data if you want to accumulate the counts.

Since the non-precise count should affect performance less, and we are splitting
it off into a second method, I suggest we make that one less intrusive, i.e. not
clear invocation counts. Fadi, what's your take on this?

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:385: "description": "Collect coverage data for
the current isolate.",
On 2017/02/16 23:04:51, pfeldman wrote:
> > Fadi wanted exactly that though. He does not care about false negatives, but
> > affecting performance would be a no go.
> 
> We need to split best effort and precise coverage accessors then. Precise
should
> be started, stopped and polled. Best effort could be just queries. In fact,
I'd
> like to learn more about the best effort data - is it even good?

Data should be fairly good still, aside from functions that get garbage
collected. The count may differ from the actual count due to optimized code not
incrementing the invocation count, but a yes/no predicate can be made.

[pfeldman, 2017-02-17 17:59:39]

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
> In that case I suggest introducing a new type for inner ranges inside the
function for future statement-level coverage.

Isn't it exactly what I suggest above in the schema? You have scripts with
functions, functions are identified by names and ranges. Each function has a
list of blocks with counters, these blocks ranges don't intersect. So we
wouldn't need to do anything with the nesting.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:381: "name": "collectCoverage",
> Since the non-precise count should affect performance less, and we are
splitting
> it off into a second method, I suggest we make that one less intrusive, i.e.
not
> clear invocation counts. Fadi, what's your take on this?

Right, Fadi's getBestEffortCoverage should not be resetting counters, only
startPreciseCoverage and takePreciseCoverage should be.

[Yang, 2017-02-20 11:24:42]

Addressed comments. Changed data structure.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:211: "properties": [
On 2017/02/16 21:23:09, pfeldman wrote:
> experimental: true

Done.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:212: { "name": "functionName", "type": "string",
"description": "JavaScript function name." },
On 2017/02/16 21:23:09, pfeldman wrote:
> Make it optional: not all of the ranges will have associated function names in
> the future.

I now changed the structure so that we have this hierarchy: ScriptCoverage ->
FunctionCoverage -> CoverageRange.

For now each function has only one CoverageRange object. But in the future this
will change.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:217: { "name": "nested", "type": "array",
"items": { "$ref": "CoverageRange" }, "description": "Nested inner coverage
ranges." },
On 2017/02/16 21:23:09, pfeldman wrote:
> I'd drop this.

Done.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/js_protoc...
src/inspector/js_protocol.json:228: { "name": "toplevel", "$ref":
"CoverageRange", "description": "Coverage ranges for the top-level function." }
On 2017/02/17 17:59:39, pfeldman wrote:
> > In that case I suggest introducing a new type for inner ranges inside the
> function for future statement-level coverage.
> 
> Isn't it exactly what I suggest above in the schema? You have scripts with
> functions, functions are identified by names and ranges. Each function has a
> list of blocks with counters, these blocks ranges don't intersect. So we
> wouldn't need to do anything with the nesting.

Done.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
File src/inspector/v8-runtime-agent-impl.cc (right):

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:650:
v8::debug::Coverage::TogglePrecise(m_inspector->isolate(), true);
On 2017/02/16 16:47:19, kozy wrote:
> We can be prepared for more then one runtime agent (bright future with multi
> client support) and implement togglePrecise on V8Debugger and store counter
> there. Like we do for enable/disable [1].
> 
> [1]
>
https://cs.chromium.org/chromium/src/v8/src/inspector/v8-debugger.cc?rcl=6346...

Done.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:655:
v8::debug::Coverage::TogglePrecise(m_inspector->isolate(), false);
On 2017/02/16 16:47:19, kozy wrote:
> - please toggle precise off in V8RuntimeAgentImpl::disable,
> - and we need to support provisional precise coverage on page reload - it
means
> that you need to store precise state in m_state, e.g.
> customObjectFormatterEnabled, and restore it in V8RuntimeAgentImpl::restore.

Done.

https://codereview.chromium.org/2700743002/diff/40001/src/inspector/v8-runtim...
src/inspector/v8-runtime-agent-impl.cc:660:
std::unique_ptr<protocol::Runtime::CoverageRange> CreateCoverageRange(
On 2017/02/16 16:47:19, kozy wrote:
> We still use not V8 code style here, let's don't mix code styles until we move
> everything to new one - createCoverageRange.

Acknowledged.

https://codereview.chromium.org/2700743002/diff/40001/test/inspector/runtime/...
File test/inspector/runtime/coverage.js (right):

https://codereview.chromium.org/2700743002/diff/40001/test/inspector/runtime/...
test/inspector/runtime/coverage.js:23: .then(() =>
Protocol.Runtime.compileScript({ expression: source, sourceURL: url,
persistScript: true }))
On 2017/02/16 16:47:19, kozy wrote:
> You can just add //# sourceURL=fib.js to your source string and use
> Protocol.Runtime.evaluate({ expression: source }) instead of compile/run
Script.

I also like to pass the URL though.

[Yang, 2017-02-21 08:40:48]

The CQ bit was checked by yangguo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-21 08:40:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-21 08:47:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-21 08:47:05]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)

[kozy, 2017-02-21 17:57:30]

lgtm

https://codereview.chromium.org/2700743002/diff/80001/test/inspector/runtime/...
File test/inspector/runtime/coverage.js (right):

https://codereview.chromium.org/2700743002/diff/80001/test/inspector/runtime/...
test/inspector/runtime/coverage.js:34: .then((result) =>
InspectorTest.logMessage(result))
.then(InspectorTest.logMessage)

https://codereview.chromium.org/2700743002/diff/80001/test/inspector/runtime/...
test/inspector/runtime/coverage.js:53: .then(() => next());
.then(next)

[pfeldman, 2017-02-21 18:32:00]

https://codereview.chromium.org/2700743002/diff/80001/src/inspector/js_protoc...
File src/inspector/js_protocol.json (right):

https://codereview.chromium.org/2700743002/diff/80001/src/inspector/js_protoc...
src/inspector/js_protocol.json:398: "name": "takeBestEffortCoverage",
getBestEffortCoverage (it does not reset, so should be prefixed with 'get'
instead of 'take').

otherwise lgtm.

[Yang, 2017-02-22 09:00:48]

On 2017/02/21 18:32:00, pfeldman wrote:
>
https://codereview.chromium.org/2700743002/diff/80001/src/inspector/js_protoc...
> File src/inspector/js_protocol.json (right):
> 
>
https://codereview.chromium.org/2700743002/diff/80001/src/inspector/js_protoc...
> src/inspector/js_protocol.json:398: "name": "takeBestEffortCoverage",
> getBestEffortCoverage (it does not reset, so should be prefixed with 'get'
> instead of 'take').
> 
> otherwise lgtm.

Addressed comments. Improved tests, fixed bug. Landing.

[Yang, 2017-02-22 09:49:31]

The CQ bit was checked by yangguo@chromium.org

[Yang, 2017-02-22 09:49:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
jgruber@chromium.org, kozyatinskiy@chromium.org, pfeldman@chromium.org
Link to the patchset: https://codereview.chromium.org/2700743002/#ps120001
(title: "addressed comments")

[commit-bot: I haz the power, 2017-02-22 09:49:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-22 09:56:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-22 09:56:17]

Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)

[Yang, 2017-02-22 09:58:50]

The CQ bit was checked by yangguo@chromium.org

[Yang, 2017-02-22 09:58:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
kozyatinskiy@chromium.org, pfeldman@chromium.org, jgruber@chromium.org
Link to the patchset: https://codereview.chromium.org/2700743002/#ps140001
(title: "fix")

[commit-bot: I haz the power, 2017-02-22 09:58:56]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-22 10:21:58]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1487757530200370,
"parent_rev": "e2de1b8696eb36256e5146d1b54cf2dda600e8d4", "commit_rev":
"901c29eb1c5783e72b8926f0a1b0d9e13b69f3c0"}

[commit-bot: I haz the power, 2017-02-22 10:22:02]

Description was changed from

==========
[inspector] extend protocol for code coverage.

R=jgruber@chromium.org, kozyatinskiy@chromium.org, pfeldman@chromium.org
BUG=v8:5808
==========

to

==========
[inspector] extend protocol for code coverage.

R=jgruber@chromium.org, kozyatinskiy@chromium.org, pfeldman@chromium.org
BUG=v8:5808

Review-Url: https://codereview.chromium.org/2700743002
Cr-Commit-Position: refs/heads/master@{#43363}
Committed:
https://chromium.googlesource.com/v8/v8/+/901c29eb1c5783e72b8926f0a1b0d9e13b6...
==========

[commit-bot: I haz the power, 2017-02-22 10:22:03]

Committed patchset #8 (id:140001) as
https://chromium.googlesource.com/v8/v8/+/901c29eb1c5783e72b8926f0a1b0d9e13b6...

[nojvek, 2017-02-24 05:40:32]

On 2017/02/22 10:22:03, commit-bot: I haz the power wrote:
> Committed patchset #8 (id:140001) as
>
https://chromium.googlesource.com/v8/v8/+/901c29eb1c5783e72b8926f0a1b0d9e13b6...

This breaks the v8 protocol schema.

https://chromium.googlesource.com/v8/v8.git/+/901c29eb1c5783e72b8926f0a1b0d9e...

Please use "experimental": true (boolean) and not "experimental: "true"
(string).

[kozy, 2017-02-24 05:51:20]

On 2017/02/24 05:40:32, nojvek wrote:
> On 2017/02/22 10:22:03, commit-bot: I haz the power wrote:
> > Committed patchset #8 (id:140001) as
> >
>
https://chromium.googlesource.com/v8/v8/+/901c29eb1c5783e72b8926f0a1b0d9e13b6...
> 
> This breaks the v8 protocol schema.
> 
>
https://chromium.googlesource.com/v8/v8.git/+/901c29eb1c5783e72b8926f0a1b0d9e...
> 
> Please use "experimental": true (boolean) and not "experimental: "true"
> (string).

I'll include this change into https://codereview.chromium.org/2715833003/. this
CL is moving coverage related methods from Runtime to Profiler.