[llvm-cov] Single file HTML output when filtering on function names.

Hi All,

Normally when producing HTML with llvm-cov you get an index.html file and a directory structure containing .html files corresponding to source files.

Currently when using any of the -name*= command line options with -format=html, the output is a single file (functions.html) containing the coverage for those specific functions.

Having a single file is not as useful as the full directory structure when you have a large number of functions in your filter (using -name-regex or -name-whitelist). Could we put the single file HTML output behind an option and produce the full structure by default when using the -name* options.

What do people think?

Thanks,

Hi All,

Normally when producing HTML with llvm-cov you get an index.html file and a directory structure containing .html files corresponding to source files.

Currently when using any of the -name*= command line options with -format=html, the output is a single file (functions.html) containing the coverage for those specific functions.

Having a single file is not as useful as the full directory structure when you have a large number of functions in your filter (using -name-regex or -name-whitelist). Could we put the single file HTML output behind an option and produce the full structure by default when using the -name* options.

This sounds fine to me. I don’t think we need to preserve the old single-file behavior. We can add a release note about the new behavior.

vedant

Hi Vedant,

This sounds fine to me. I don’t think we need to preserve the old single-file behavior. We can add a release note about the new behavior.

Great!

I’d like to change the index.html page to only include coverage data for the filtered functions and do the same for all the ‘source view’ pages.

For the index.html page I plan to do the filtering in CoverageReport::prepareFileReports, which will be quite simple.

Filtering the lines in the source files will be more complicated, as I will need to find which function a LineSegment comes from. I think I can do that by getting the function coverage for each filtered function from the same file, and then checking if the line segment can be found in any of those. I was wondering if you can think of a better way of mapping from lines to functions or if you might have something else in mind?

Thanks for your help,

Hi Vedant,

This sounds fine to me. I don’t think we need to preserve the old single-file behavior. We can add a release note about the new behavior.

Great!

I’d like to change the index.html page to only include coverage data for the filtered functions and do the same for all the ‘source view’ pages.

For the index.html page I plan to do the filtering in CoverageReport::prepareFileReports, which will be quite simple.

Filtering the lines in the source files will be more complicated, as I will need to find which function a LineSegment comes from. I think I can do that by getting the function coverage for each filtered function from the same file, and then checking if the line segment can be found in any of those. I was wondering if you can think of a better way of mapping from lines to functions or if you might have something else in mind?

I’m not sure it’s necessary to map lines to functions. One alternative is to create a SourceCoverageView for each filtered function, maintaining a map from filenames to coverage views. When you’re done creating all the views, you can walk over the map, emitting all the views for each file. Wdyt?

vedant