Coverage: add a trace for not_covered_lines per file

Coverage: add a trace for not_covered_lines per file

Example output:

{
    "build_number": "2",
    "gitHash": "71f5db892ee7ed9fbb573da28ccb906e18ba24a4",
    "key": {
        "arch": "x86_64",
        "compiler": "Clang",
        "configuration": "Coverage",
        "cpu_or_gpu": "CPU",
        "cpu_or_gpu_value": "AVX2",
        "model": "GCE",
        "os": "Ubuntu"
    },
    "results": {
        "dm_DMGpuSupport_h": {
            "coverage": {
                "lines_not_covered": 6,
                "options": {
                    "dir": "dm",
                    "fullname": "dm/DMGpuSupport.h",
                    "source_type": "coverage"
                },
                "percent": 33.33333333333333
            }
        },
        "dm_DMJsonWriter_cpp": {
......


BUG=skia:2430
Committed: https://skia.googlesource.com/skia/+/4cb300340eb525b2ee2a73d12d81cbfd3b746498

[borenet, 2015-07-21 17:43:25]

borenet@google.com changed reviewers:
+ jcgregorio@google.com, stephana@google.com

[borenet, 2015-07-21 17:43:25]

Let me know if the format looks wrong.

[jcgregorio, 2015-07-22 04:24:29]

jcgregorio@google.com changed reviewers:
+ mtklein@google.com
- jcgregorio@google.com

[jcgregorio, 2015-07-22 04:24:58]

jcgregorio@google.com changed reviewers:
+ jcgregorio@google.com

[jcgregorio, 2015-07-22 04:24:58]

+mktlein for nanobench output

[mtklein, 2015-07-22 12:20:26]

https://codereview.chromium.org/1246043002/diff/20001/tools/parse_llvm_covera...
File tools/parse_llvm_coverage.py (left):

https://codereview.chromium.org/1246043002/diff/20001/tools/parse_llvm_covera...
tools/parse_llvm_coverage.py:108: 'coverage': {
Am I remembering this format wrong or do we want it like this?

'coverage': {
  'percent': percent,
  'lines_not_covered': lines_not_covered,
  'options': {
     'fullname': f,
     'dir': os.path.dirname(f),
     'source_type': 'coverage',
  }
}

Though, 'coverage' is already splattered around there enough that I don't know
we're going to get any real value from an extra source_type: coverage.  

I'm pretty sure source_type does not belong in the key, though.  The key
determines the identity of the trace (line on perf) so it wouldn't hurt here
(adding anything wouldn't hurt as long as it was always the same anything) but
it's also not necessary unless we're trying to make a distinction.  E.g., if we
had two different ways of getting coverage on the same machine and we wanted to
plot them as two lines, we'd need to make sure the key had 'coverage_tool:
clang' or 'coverage_tool: gcov'  (or whatever).

[borenet, 2015-07-22 13:01:59]

Edited the issue description with new format.

https://codereview.chromium.org/1246043002/diff/20001/tools/parse_llvm_covera...
File tools/parse_llvm_coverage.py (left):

https://codereview.chromium.org/1246043002/diff/20001/tools/parse_llvm_covera...
tools/parse_llvm_coverage.py:108: 'coverage': {
On 2015/07/22 12:20:26, mtklein wrote:
> Am I remembering this format wrong or do we want it like this?
> 
> 'coverage': {
>   'percent': percent,
>   'lines_not_covered': lines_not_covered,
>   'options': {
>      'fullname': f,
>      'dir': os.path.dirname(f),
>      'source_type': 'coverage',
>   }
> }
> 
> Though, 'coverage' is already splattered around there enough that I don't know
> we're going to get any real value from an extra source_type: coverage.  
> 
> I'm pretty sure source_type does not belong in the key, though.  The key
> determines the identity of the trace (line on perf) so it wouldn't hurt here
> (adding anything wouldn't hurt as long as it was always the same anything) but
> it's also not necessary unless we're trying to make a distinction.  E.g., if
we
> had two different ways of getting coverage on the same machine and we wanted
to
> plot them as two lines, we'd need to make sure the key had 'coverage_tool:
> clang' or 'coverage_tool: gcov'  (or whatever).

So one of my concerns was preventing clustering with actual perf results; I was
hoping that providing source_type might cause that to happen.  From what I could
tell, putting source_type in the key section caused it to apply to all of the
results, which saves some space over including it in each result.  It's no
problem to move it though.

[mtklein, 2015-07-22 15:10:39]

lgtm

Yeah, having source_type in options will do what you want I think, minus the
unwanted baggage of not being part of the trace's identity.

[borenet, 2015-07-22 15:11:16]

On 2015/07/22 15:10:39, mtklein wrote:
> lgtm
> 
> Yeah, having source_type in options will do what you want I think, minus the
> unwanted baggage of not being part of the trace's identity.

Sounds good!

[borenet, 2015-07-22 15:11:18]

The CQ bit was checked by borenet@google.com

[commit-bot: I haz the power, 2015-07-22 15:11:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1246043002/40001

[commit-bot: I haz the power, 2015-07-22 15:19:29]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/4cb300340eb525b2ee2a73d12d81cbfd3b746498