Bug 149248 - Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
Summary: Web Inspector: Basic Block Annotations and Type Profiler annotations wrong fo...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Saam Barati
URL:
Keywords: InRadar
Depends on: 149427 149429
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-16 22:31 PDT by Joseph Pecoraro
Modified: 2015-09-22 00:45 PDT (History)
9 users (show)

See Also:


Attachments
[IMAGE] Issue (10.67 KB, image/png)
2015-09-16 22:31 PDT, Joseph Pecoraro
no flags Details
patch (3.85 KB, patch)
2015-09-21 13:06 PDT, Saam Barati
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Pecoraro 2015-09-16 22:31:15 PDT
* SUMMARY
Basic Block Annotations and Type Profiler annotations wrong for script with "class".

* TEST (bad-script.js)
var a;
var b = 1;
var c = 1;
class Foo {};

* STEPS TO REPRODUCE
1. Turn on the Type Profiler / Code Coverage
2. Run the above script
  => mis-highlighted regions and types
Comment 1 Joseph Pecoraro 2015-09-16 22:31:44 PDT
Created attachment 261369 [details]
[IMAGE] Issue
Comment 2 Saam Barati 2015-09-16 23:07:12 PDT
This seems like a bug in JSC. I'll take it
Comment 3 Saam Barati 2015-09-21 11:42:08 PDT
I think the problem here has to do with default constructors.
Comment 4 Radar WebKit Bug Importer 2015-09-21 11:42:20 PDT
<rdar://problem/22785402>
Comment 5 Saam Barati 2015-09-21 12:48:48 PDT
(In reply to comment #3)
> I think the problem here has to do with default constructors.

It does. And their bogus "text ranges" that we interpret as being part of the user program's source code. It's obviously not. 
We parse these default constructors from C++ Strings we create.
Comment 6 Saam Barati 2015-09-21 13:06:15 PDT
Created attachment 261679 [details]
patch

This is one possible solution.
Another solution is to set a bit on
UnlinkedFunctionExecutable indicating it's a default
constructor (or we can generalize the bit to mean that
this thing was created outside the user's source code).
And, if that bit is set, we will not insert the function
as an unexecuted range.
Comment 7 Mark Lam 2015-09-21 13:17:52 PDT
Comment on attachment 261679 [details]
patch

r=me
Comment 8 WebKit Commit Bot 2015-09-21 15:42:31 PDT
Comment on attachment 261679 [details]
patch

Clearing flags on attachment: 261679

Committed r190086: <http://trac.webkit.org/changeset/190086>
Comment 9 WebKit Commit Bot 2015-09-21 15:42:34 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 WebKit Commit Bot 2015-09-21 15:56:20 PDT
Re-opened since this is blocked by bug 149427
Comment 11 Saam Barati 2015-09-22 00:45:36 PDT
landed in:
http://trac.webkit.org/changeset/190108