digitalmars.D - Anyone in touch with codecov team ? We need assert(0); and
- Basile B. (14/14) Feb 11 2021 Just like exposed in the title, every assert(false); and
- Iain Buclaw (7/11) Feb 11 2021 My first question would be whether they have this special case
- Basile B. (7/18) Feb 11 2021 `"Every line that is not covered should be be considered as a
- Vladimir Panteleev (13/27) Feb 11 2021 I think the appropriate place to fix this would be in the
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 2021
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 2021
Basile B. <b2.temp gmx.com> 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:`"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.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 2021
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 2021
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:yeah that's a nice alternative, no need to mess with the codecov team if we truncate the report.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
Feb 11 2021
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:https://issues.dlang.org/show_bug.cgi?id=21630On Thursday, 11 February 2021 at 11:17:29 UTC, Basile B. wrote:yeah that's a nice alternative, no need to mess with the codecov team if we truncate the report.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
Feb 11 2021
On Thursday, 11 February 2021 at 13:54:29 UTC, Basile B. wrote: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)`.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
Jun 06 2021