https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

Yeah: https://issues.dlang.org/buglist.cgi?quicksearch=coverage&list_id=209269

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

I've reported this one a while back:

https://issues.dlang.org/show_bug.cgi?id=15590

if (__ctfe) branches are a problem because they really prevent to reach 100% coverage. D code similar to std.traits content is also a problem, it's never executed at run-time.

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov.

On 7/1/16 2:05 PM, Chris wrote:
> On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
>> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
>
> I fail to see why it should not mark it as uncovered in the `cube`
> example. After all the statement is never covered, because `do` executes
> before the condition in `while` is checked. Unless you mean it should be
> optimized away by the compiler, which in turn has nothing to do with -cov.

Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei

On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote:
>
> Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei

Not sure if it's pure punctuation. It is after all a statement checking for a condition, i.e. actually doing something. The fact that you bypass this check should not concern -cov, whose job it is to see whether a task is executed or not. You cannot expect -cov to do the optimizer's job on top of that. In fact one could argue that it shouldn't make assumptions.

On 7/1/16 2:15 PM, Andrei Alexandrescu wrote:
> On 7/1/16 2:05 PM, Chris wrote:
>> On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
>>> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
>>
>> I fail to see why it should not mark it as uncovered in the `cube`
>> example. After all the statement is never covered, because `do` executes
>> before the condition in `while` is checked. Unless you mean it should be
>> optimized away by the compiler, which in turn has nothing to do with
>> -cov.
>
> Yah it's a bit subtle. That line is in fact pure punctuation, so even
> though there's no flow through it that's totally fine (as much as you
> wouldn't expect a line with a "}" to show no coverage). -- Andrei

Suppose one wants to check if you've covered all cases inside the while loop (with breaks or returns). Then, one would WANT to see 0 coverage there (non-zero coverage would mean an error in logic).

To remove that feedback would mess up someone else's use case.

-Steve

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

That

    do {
    } while(0)

construct is ridiculous. It's cargo cult at its worst. It is NOT more readable than an honest to god goto. It's an obfuscated way to write naughty gotos without the guilt of sinning (I deliberately use religous vocabulary because it is a religious disease). It's the goto of the hypocrits.
Sorry if I sound harsh, but I share a project (in C) with a colleague who loves that construct and after almost 15 years of having to debug that sh... I can affirm that that construct is a scourge and deserves all the scorn that can be heaped on it.
It looks like a loop, but isn't one.
It doesn't look like a goto, but is one.
It's horribly difficult to amend, especially if there is actually a real loop somewhere around or inside it.
It pushes the user to write unnecessary big functions (anecdote, I modified once a 200 lines do while(0) behemoth that could be reduced to 4 functions of 10 lines each and a small loop. After conversion and simplification I discovered that the original didn't even cover all functional cases and leaked some memory).
I don't think it makes even an inkling of sense to use it in D as there are real language constructs that can cleanly replace it (scope, try/catch/finally, destructors, etc.).

On 7/1/16 2:27 PM, Chris wrote:
> On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote:
>>
>> Yah it's a bit subtle. That line is in fact pure punctuation, so even
>> though there's no flow through it that's totally fine (as much as you
>> wouldn't expect a line with a "}" to show no coverage). -- Andrei
>
> Not sure if it's pure punctuation. It is after all a statement checking
> for a condition

What is the condition? -- Andrei

On 7/1/16 2:46 PM, Steven Schveighoffer wrote:
> On 7/1/16 2:15 PM, Andrei Alexandrescu wrote:
>> On 7/1/16 2:05 PM, Chris wrote:
>>> On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
>>>> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
>>>
>>> I fail to see why it should not mark it as uncovered in the `cube`
>>> example. After all the statement is never covered, because `do` executes
>>> before the condition in `while` is checked. Unless you mean it should be
>>> optimized away by the compiler, which in turn has nothing to do with
>>> -cov.
>>
>> Yah it's a bit subtle. That line is in fact pure punctuation, so even
>> though there's no flow through it that's totally fine (as much as you
>> wouldn't expect a line with a "}" to show no coverage). -- Andrei
>
> Suppose one wants to check if you've covered all cases inside the while
> loop (with breaks or returns). Then, one would WANT to see 0 coverage
> there (non-zero coverage would mean an error in logic).
>
> To remove that feedback would mess up someone else's use case.

This argument is phony. Unconvinced. -- Andrei