Date: Wed, 14 Mar 2018 17:02:40 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Stephen Frost <sfrost@snowman.net>,
	Magnus Hagander <magnus@hagander.net>,
	PostgreSQL WWW <pgsql-www@lists.postgresql.org>
Subject: Re: Bogus reports from coverage.postgresql.org
Message-ID: <20180314200240.t2un5u2eybudldtv@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <12595.1521057160@sss.pgh.pa.us>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

Tom Lane wrote:

> Well, this is darn interesting.  I got the Fedora lcov maintainer
> to push an update absorbing the upstream "gcc 8" fixes.  (Turned
> out he'd already done that for rawhide, but forgot to push it into
> the F28 branch.)  And with that, and gcc 8.0.1, ... no bug.  The
> lines are marked "lineNoCov" with or without lcov_branch_coverage.

Hmm.  I wonder if this means that the reports generated with any
compiler prior to gcc 8 are unreliable.  At least we know now that that
is indeed the case with branch coverage, but what about without?

While we're on this topic ...  Some time ago, I looked into whether it
would be possible to make the coverage report ignore the elog(ERROR)
lines, which are --or should be-- unreachable code and thus we don't
care too much about test coverage.  Finding no way to implement that, I
gave up (I tried adding exclusion markers in the elog definition, as
documented in geninfo.  Perhaps I did it wrong).  But maybe it is
possible with these recent improvements?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services