summaryrefslogtreecommitdiffstats
path: root/clang/test/CoverageMapping/trycatch.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Coverage] Discard the last uncompleted deferred region in a declVedant Kumar2018-05-301-1/+1
| | | | | | | | | | | | | | | | | | | Discard the last uncompleted deferred region in a decl, if one exists. This prevents lines at the end of a function containing only whitespace or closing braces from being marked as uncovered, if they follow a region terminator (return/break/etc). The previous behavior was to heuristically complete deferred regions at the end of a decl. In practice this ended up being too brittle for too little gain. Users would complain that there was no way to reach full code coverage because whitespace at the end of a function would be marked uncovered. rdar://40238228 Differential Revision: https://reviews.llvm.org/D46918 llvm-svn: 333609
* [Coverage] Emit a gap area after if conditionsVedant Kumar2017-11-091-3/+3
| | | | | | | | | | | | | | | | | | | The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758
* [Coverage] Precise region termination with deferred regions (reapply)Vedant Kumar2017-09-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang This is a reapplication but there are no changes from the original commit. With D36813, the segment builder in llvm will be able to handle deferred regions correctly. llvm-svn: 312818
* Revert "[Coverage] Precise region termination with deferred regions"Vedant Kumar2017-08-051-1/+1
| | | | | | | | | | | | | | This reverts commit r310010. I don't think there's anything wrong with this commit, but it's causing clang to generate output that llvm-cov doesn't do a good job with and the fix isn't immediately clear. See Eli's comment in D36250 for more context. I'm reverting the clang change so the coverage bot can revert back to producing sensible output, and to give myself some time to investigate what went wrong in llvm. llvm-svn: 310154
* [Coverage] Precise region termination with deferred regionsVedant Kumar2017-08-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang llvm-svn: 310010
* [Coverage] Push a new region when handling CXXTryStmtsVedant Kumar2016-06-221-1/+1
| | | | | | | | 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. llvm-svn: 273463
* [PGO] cc1 option name change for profile instrumentationRong Xu2016-02-041-1/+1
| | | | | | | | | | | | This patch changes cc1 option -fprofile-instr-generate to an enum option -fprofile-instrument={clang|none}. It also changes cc1 options -fprofile-instr-generate= to -fprofile-instrument-path=. The driver level option -fprofile-instr-generate and -fprofile-instr-generate= remain intact. This change will pave the way to integrate new PGO instrumentation in IR level. Review: http://reviews.llvm.org/D16730 llvm-svn: 259811
* InstrProf: Mark code regions after throw expressions as unreachableJustin Bogner2015-04-281-6/+8
| | | | | | | We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
* InstrProf: Always emit a coverage region for the condition of an ifJustin Bogner2015-02-191-3/+4
| | | | | | | | When tools like llvm-cov show regions, it's much easier to understand what's happening if the condition of an if shows a counter as well as the body. llvm-svn: 229813
* InstrProf: Rewrite most of coverage mapping generation in a simpler wayJustin Bogner2015-02-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
* InstrProf: Remove CoverageMapping::HasCodeBefore, it isn't usedJustin Bogner2015-02-031-9/+9
| | | | llvm-svn: 228035
* Add tests for coverage mapping generation.Alex Lorenz2014-08-191-0/+34
| | | | | | | | | | This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4847 llvm-svn: 215995
* Revert "Add tests for coverage mapping generation."Justin Bogner2014-08-091-50/+0
| | | | | | | | | | | | | | | I reverted one of the added tests from r215261 in r215274, since it was failing on quite a few bots. It looks like this wasn't sufficient, as we're still getting failures on windows, like the following: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/5378 I'm reverting this entire commit so the bots aren't blocked on these failures. This reverts commit r215261. llvm-svn: 215278
* Add tests for coverage mapping generation.Alex Lorenz2014-08-081-0/+50
This patch adds the tests for the coverage mapping generation. Most of the tests check the mapping regions produced by the generator, and one checks the llvm IR. Differential Revision: http://reviews.llvm.org/D4793 llvm-svn: 215261
OpenPOWER on IntegriCloud