[PATCH] fix incorrect documentation for coverage-data->lcov

[PATCH] fix incorrect documentation for coverage-data->lcov

[Peter Elliott]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

Hello,
coverage-data->lcov does not, and never has taken a 'modules'
argument, so I've removed it.
However, I would really like this, and might add it if it's not too hard.

[-- Attachment #2: 0001-Remove-modules-arg-from-coverage-data-lcov-doc.patch --]
[-- Type: text/x-patch, Size: 1387 bytes --]

From e0dbb70625d1dd850924122c64639994e2fed3b5 Mon Sep 17 00:00:00 2001
From: Peter Elliott <pelliott@ualberta.ca>
Date: Tue, 27 Aug 2019 20:19:15 -0700
Subject: [PATCH] Remove modules arg from coverage data->lcov doc

---
 doc/ref/api-coverage.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/ref/api-coverage.texi b/doc/ref/api-coverage.texi
index 5081d343b..92ae606b6 100644
--- a/doc/ref/api-coverage.texi
+++ b/doc/ref/api-coverage.texi
@@ -25,12 +25,12 @@ Return @code{#t} if @var{obj} is a @dfn{coverage data} object as returned by
 @code{with-code-coverage}.
 @end deffn
 
-@deffn {Scheme Procedure} coverage-data->lcov data port #:key modules
+@deffn {Scheme Procedure} coverage-data->lcov data port
 Traverse code coverage information @var{data}, as obtained with
 @code{with-code-coverage}, and write coverage information to port in the
 @code{.info} format used by @url{http://ltp.sourceforge.net/coverage/lcov.php,
-LCOV}.  The report will include all of @var{modules} (or, by default, all the
-currently loaded modules) even if their code was not executed.
+LCOV}.  The report will include all the modules loaded at the time coverage data was
+gathered, even if their code was not executed.
 
 The generated data can be fed to LCOV's @command{genhtml} command to produce an
 HTML report, which aids coverage data visualization.
-- 
2.22.1

Re: [PATCH] fix incorrect documentation for coverage-data->lcov

[Timothy Sample]

Hi Peter,

Peter Elliott <pelliott@ualberta.ca> writes:

> Hello,
> coverage-data->lcov does not, and never has taken a 'modules'
> argument, so I've removed it.
> However, I would really like this, and might add it if it's not too hard.

I submitted a patch for this a little while ago:

    https://lists.gnu.org/archive/html/guile-devel/2017-12/msg00006.html

My knowledge of the Guile internals was and is pretty limited, but the
patch worked for my purposes.  Maybe it would be useful to you, too.

The only part that is weird in my patch (in retrospect) is that the
“modules” parameter is a list of filenames.  The name doesn’t really
make the parameter type clear (it could be a list of modules objects or
a list of modules like you pass to “use-modules”).

I used it by filtering the results of “instrumented-source-files”:

    (let ((modules (filter project-file?
                           (instrumented-source-files data))))
      (coverage-data->lcov data port #:modules modules))

where “project-file?” tests if a file is part of the current project (as
opposed to part of Guile or another library).

Hope that helps!


-- Tim