Why is a closing brace showing no code coverage?

Question

I've got a Swift function for which Xcode is showing 0 passes in code coverage. The line is a closing brace (highlighted in red below).

Is this a bug in Xcode? If not, what condition do I need to hit to run that line? I thought I was covering all paths through this method.

Sideburns

Ever figure out a way to silence this Xcode issue? – Scrivenor

@AdamJohns I haven't seen it happen recently - but I haven't been working on this code in a while. You're still seeing it with Xcode 8? – Sideburns

Still seeing this in Xcode10b6. Reported as rdar://43697191 (openradar.appspot.com/radar?id=4958257156194304) – Rocray

Answer 1

Pretty sure this is a bug (feature?) of Xcode code coverage. The issue boils down to the return statement not allowing it to fall down to the empty else statement, thus indicating the code is not executed. The return statements throw a wrench into whatever they are doing to count the lines of code.

In the instance of your try/catch block, you don't really have much choice there to prevent the empty execution.

As an experiment, remove the return statement and find a better way to catch the writeToURL statement so it doesn't execute in an error/catch statement. That will likely give you clean code coverage for that line.

Sivia

Answer 2

xcode reports include measurements for ending brackets, which is not typically desired. There is nothing you can do in configuration to fix this (as far as I know).

(FD I work at Codecov) You can use Codecov, a hosted solution, that will remove these extra lines automatically. Learn more at https://github.com/codecov/example-xcode. Thanks :)

Woden

But then why isn't this happening everywhere? Most of my classes and functions are covered at 100% – Sideburns

Excellent question, unfortunately I do not have an answer. – Woden

I'm curios about this too. – Omarr

Answer 3

In case you still got this issue, try adding the compile options -fno-elide-constructors and -fno-default-inline in addition to -fprofile-arcs and -ftest-coverage as it may also help with coverage of "missing" constructors and inline functions. This fixed a similar issue for me when I was using GNU/GCC 11.3.

Wilbur