After r275121, we stopped mapping regions from system headers. Lambdas
declared in regions belonging to system headers started producing empty
coverage mappings, since the files corresponding to their spelling locs
were being ignored.
The coverage reader doesn't know what to do with these empty mappings.
This commit makes sure that we don't produce them and adds a test. I'll
make the reader stricter in a follow-up commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276716 91177308-0d34-0410-b5e6-96231b3b80d8
Failure to do this breaks relative paths which begin with '..'.
This issue was caught by the (still nascent) coverage bot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275924 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the issue of having duplicate entries for the same file in a
coverage report s.t none of the entries actually displayed the correct
coverage information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275913 91177308-0d34-0410-b5e6-96231b3b80d8
Do not assign source regions located within system headers file ID's,
and do not construct counter mapping regions out of them.
This makes coverage reports less cluttered and less mysterious. E.g
using the "assert" macro doesn't cause assert.h to appear in reports,
and it no longer shows the "assertion failed" branch as an uncovered
region.
It also makes coverage mapping sections a bit smaller (e.g a 1%
reduction in a stage2 build of bin/llvm-as).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275121 91177308-0d34-0410-b5e6-96231b3b80d8
Push a new region for the try block and propagate execution counts
through it. This ensures that catch statements get a region counter
distinct from the try block's counter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273463 91177308-0d34-0410-b5e6-96231b3b80d8
We have an assertion failure if, for example, the definition of an unused
inline function starts in one macro and ends in another. This patch fixes
the issue by finding the common ancestor of the start and end locations
of that function's body and changing the locations accordingly.
Thanks to NAKAMURA Takumi for helping with fixing the test failure on Windows.
Differential Revision: http://reviews.llvm.org/D20997
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271995 91177308-0d34-0410-b5e6-96231b3b80d8
We have an assertion failure if, for example, the definition of an unused
inline function starts in one macro and ends in another. This patch fixes
the issue by finding the common ancestor of the start and end locations
of that function's body and changing the locations accordingly.
Differential Revision: http://reviews.llvm.org/D20997
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271969 91177308-0d34-0410-b5e6-96231b3b80d8
I added this call in r271308. It's redundant because it's dominated by a
call to extendRegion().
Thanks to Justin Bogner for pointing this out!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271331 91177308-0d34-0410-b5e6-96231b3b80d8
While pushing switch statements onto the region stack we neglected to
specify their start/end locations. This results in a crash (PR26825) if
we end up in nested macro expansions without enough information to
handle the relevant file exits.
I added a test in switchmacro.c and fixed up a bunch of incorrect CHECK
lines that specify strange end locations for switches.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262697 91177308-0d34-0410-b5e6-96231b3b80d8
When handling 'if' statements, we crash if the condition and the consequent
branch are spanned by a single macro expansion.
The crash occurs because of a sanity 'reset' in popRegions(): if an expansion
exactly spans an entire region, we set MostRecentLocation to the start of the
expansion (its 'include location'). This ensures we don't handleFileExit()
ourselves out of the expansion before we're done processing all of the regions
within it. This is tested in test/CoverageMapping/macro-expressions.c.
This causes a problem when an expansion spans both the condition and the
consequent branch of an 'if' statement. MostRecentLocation is updated to the
start of the 'if' statement in popRegions(), so the file for the expansion
isn't exited by the time we're done handling the statement. We then crash with
'fatal: File exit not handled before popRegions'.
The fix for this is to detect these kinds of expansions, and conservatively
update MostRecentLocation to the end of expansion region containing the
conditional. I've added tests to make sure we don't have the same problem with
other kinds of statements.
rdar://problem/23630316
Differential Revision: http://reviews.llvm.org/D16934
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260129 91177308-0d34-0410-b5e6-96231b3b80d8
Coverage mapping data may reference names of functions
that are skipped by FE (e.g, unused inline functions). Since
those functions are skipped, normal instr-prof function lowering
pass won't put those names in the right section, so special
handling is needed to walk through coverage mapping structure
and recollect the references.
With this patch, only names that are skipped are processed. This
simplifies the lowering code and it no longer needs to make
assumptions coverage mapping data layout. It should also be
more efficient.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257092 91177308-0d34-0410-b5e6-96231b3b80d8
This is one last remaining instrumentatation related structure
that needs to be migrate to use the centralized template
definition. With this change, instrumentation code
related to coverage module header will be kept in sync
with the coverage mapping reader. The remaining code
which makes implicit assumption about covmap control
structure layout in the the lowering pass will cleaned
up in a different patch. This patch is not intended to
have no functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256714 91177308-0d34-0410-b5e6-96231b3b80d8
In llvm commit r243581, a reverse range adapter was added which allows
us to change code such as
for (auto I = Fields.rbegin(), E = Fields.rend(); I != E; ++I) {
in to
for (const FieldDecl *I : llvm::reverse(Fields))
This commit changes a few of the places in clang which are eligible to use
this new adapter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243663 91177308-0d34-0410-b5e6-96231b3b80d8
The catch keyword isn't really part of a region, so it's fairly
meaningless to extend into it. This was usually harmless, but it could
crash when catch blocks involved macros in strange ways.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243066 91177308-0d34-0410-b5e6-96231b3b80d8
If this assert does fire, the no-asserts behaviour is an infinite
loop. It's better to crash in this case so we get a crash report and
stop wasting the user's cpu cycles.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242591 91177308-0d34-0410-b5e6-96231b3b80d8
The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241300 91177308-0d34-0410-b5e6-96231b3b80d8
When we read this data we treat it as unaligned and packed, so we
should really be explicit about that when we write it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241218 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
We were propagating the coverage map into the body of an if statement,
but not into the condition thereafter. This is fine as long as the two
locations are in the same virtual file, but they won't be when the
"if" part of the statement is from a macro and the condition is not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239803 91177308-0d34-0410-b5e6-96231b3b80d8
The issue I was trying to solve in r236547 was about built-in macros,
but I disabled coverage in all system macros. This is actually a bit
of overkill, and makes the display of coverage around system macros
degrade unnecessarily. Instead, limit this to builtins specifically.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237397 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't make much sense to try to show coverage inside system
macros, and source locations in builtins confuses the coverage
mapping. Just avoid doing this.
Fixes an assert that fired when a __block storage specifier starts a
region.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236547 91177308-0d34-0410-b5e6-96231b3b80d8
We weren't setting regions as being unreachable after C++ throw
expressions, leading to incorrect count propagations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235967 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a crash when we're emitting coverage and a macro appears
between two binary conditional operators, ie, "foo ?: MACRO ?: bar",
and fixes the interaction of macros and conditional operators in
general.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235793 91177308-0d34-0410-b5e6-96231b3b80d8
When we try to find the end loc for a token, we have to re-lex the
token. This was running into a problem when we'd store the end loc of
a macro's coverage region, since we wouldn't actually be at the
beginning of a token when we tried to re-lex it, leading us to do
silly things (and eventually assert) when whitespace or comments
followed.
This pushes our use of getPreciseTokenLocEnd earlier, so that we won't
call it when it doesn't make sense to. It also removes an unnecessary
adjustment by 1 that was working around this problem in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233169 91177308-0d34-0410-b5e6-96231b3b80d8
When generating coverage maps, we were traversing the body as if it
were part of the parent function, but this doesn't make sense since
we're currently counting lambdas as separate functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230304 91177308-0d34-0410-b5e6-96231b3b80d8
Vedant Kumar