Has there been any thought put into generating code coverage reports for
the compiler? Or, are there some known steps community members could take
to help out (such as adding a flag to build-script which enables
-fprofile-arcs -ftest-coverage)?
I think it'd be really interesting to see what's covered by the
(validation) tests and what isn't.
which will rebuild the compiler with coverage instrumentation and run all the tests you've selected with coverage enabled.
Once all the tests are done, you'll get a set of .profraw files in the swift-test-results directory. Just merge them together with
llvm-profdata merge *.profraw -o swiftc.profdata
and you can use llvm-cov to inspect that data.
Note: you'll need to build swift with an upstream version of llvm and clang, because there's a very recent 'pooled' coverage system that we use.
You'll probably see that coverage is really low, somewhere around ~50%. It's that low because the coverage technically considers _all files_, including those from llvm and clang. Those files are, naturally, not tested by the Swift test suite, so they contribute a significant amount of 'un-covered' areas.
When we isolate the Swift compiler's files, I found that coverage was somewhere around 79.45%
If you need any help, let me know!
-- Harlan
···
On Aug 25, 2016, at 2:46 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org> wrote:
Has there been any thought put into generating code coverage reports for the compiler? Or, are there some known steps community members could take to help out (such as adding a flag to build-script which enables -fprofile-arcs -ftest-coverage)?
I think it'd be really interesting to see what's covered by the (validation) tests and what isn't.
This is a thread from the last decade about incorporating features into the compiler. Please post any questions about using Swift in a new, separate thread under "Using Swift," and any issues with compiling the compiler itself in a new thread under the "Development" category. Thanks!