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.

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.

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.

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?)

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.

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