www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Anyone in touch with codecov team ? We need assert(0); and

reply Basile B. <b2.temp gmx.com> writes:
Just like exposed in the title, every assert(false); and 
assert(0); line is counted as not covered by CodeCov reports. But 
given D semantics, this is really not supposed to be covered. If 
at some point this is covered this mean that your program has 
crashed and that you will fix something and finally you see that 
the objective here is really that those special assertions must 
not be covered.

If anyone is in touch with codecov or has been, it's been nice to 
suggest those two statements in their ignore rules (just like 
curly braces).

I see criticism comming, such as "they cannot handle 
assert(/*yeah*/false/**/)", but I think that this does not 
matter. The regexes for the two most common cases would be great 
to get more accurate reports.
Feb 11
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:
 I see criticism comming, such as "they cannot handle 
 assert(/*yeah*/false/**/)", but I think that this does not 
 matter. The regexes for the two most common cases would be 
 great to get more accurate reports.
My first question would be whether they have this special case for C/C++ (such as __builtin_unreachable()). There's nothing to prevent us rewriting the compiler/library code in such a way that it becomes covered. But I'd have thought that coverage would be the least interesting part of the CI pipeline results.
Feb 11
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 11 February 2021 at 11:51:26 UTC, Iain Buclaw wrote:
 On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:
 I see criticism comming, such as "they cannot handle 
 assert(/*yeah*/false/**/)", but I think that this does not 
 matter. The regexes for the two most common cases would be 
 great to get more accurate reports.
My first question would be whether they have this special case for C/C++ (such as __builtin_unreachable()). There's nothing to prevent us rewriting the compiler/library code in such a way that it becomes covered. But I'd have thought that coverage would be the least interesting part of the CI pipeline results.
`"Every line that is not covered should be be considered as a bug" changed my life` More seriously metaprog and templates make coverage results really meaningless but if you write classic imperative and eventually also structured code without templates coverage means more.
Feb 11
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:
 Just like exposed in the title, every assert(false); and 
 assert(0); line is counted as not covered by CodeCov reports. 
 But given D semantics, this is really not supposed to be 
 covered. If at some point this is covered this mean that your 
 program has crashed and that you will fix something and finally 
 you see that the objective here is really that those special 
 assertions must not be covered.

 If anyone is in touch with codecov or has been, it's been nice 
 to suggest those two statements in their ignore rules (just 
 like curly braces).

 I see criticism comming, such as "they cannot handle 
 assert(/*yeah*/false/**/)", but I think that this does not 
 matter. The regexes for the two most common cases would be 
 great to get more accurate reports.
I think the appropriate place to fix this would be in the compiler. This is where the information of whether a line is eligible for coverage originates. (In DMD listings, it's the difference between a line starting with " |" and "0000000|".) I think you also ideally want this to apply to basic blocks which are guaranteed to end with an assert(0), e.g.: default: logFatal("This should never happen!"); assert(false); as well as functions which do this or otherwise never return. (DIP 1017?)
Feb 11
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 11 February 2021 at 12:30:36 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:
 I see criticism comming, such as "they cannot handle 
 assert(/*yeah*/false/**/)", but I think that this does not 
 matter. The regexes for the two most common cases would be 
 great to get more accurate reports.
I think the appropriate place to fix this would be in the compiler. This is where the information of whether a line is eligible for coverage originates. (In DMD listings, it's the difference between a line starting with " |" and
yeah that's a nice alternative, no need to mess with the codecov team if we truncate the report.
Feb 11
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 11 February 2021 at 13:27:45 UTC, Basile B. wrote:
 On Thursday, 11 February 2021 at 12:30:36 UTC, Vladimir 
 Panteleev wrote:
 On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:
 I see criticism comming, such as "they cannot handle 
 assert(/*yeah*/false/**/)", but I think that this does not 
 matter. The regexes for the two most common cases would be 
 great to get more accurate reports.
I think the appropriate place to fix this would be in the compiler. This is where the information of whether a line is eligible for coverage originates. (In DMD listings, it's the difference between a line starting with " |" and
yeah that's a nice alternative, no need to mess with the codecov team if we truncate the report.
https://issues.dlang.org/show_bug.cgi?id=21630
Feb 11
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 11 February 2021 at 13:54:29 UTC, Basile B. wrote:
 yeah that's a nice alternative, no need to mess with the 
 codecov team if we truncate the report.
https://issues.dlang.org/show_bug.cgi?id=21630
The change is now live in 2.097. For example in styx CI, after updating the compiler used I get a [+ 0.57%](https://codecov.io/gl/styx-lang/styx/commit/017e606fa1adf8eba0abebc5fa2883dd305de6da/). So in theory now it's possible to reach 100% without using tricks to avoid `assert(0)`.
Jun 06