aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CoverageMappingGen.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-07-01[Coroutines] Fix code coverage for coroutineXun Li1-0/+12
Summary: Previously, source-based coverage analysis does not work properly for coroutine. This patch adds processing of coroutine body and co_return in the coverage analysis, so that we can handle them properly. For coroutine body, we should only look at the actual function body and ignore the compiler-generated things; for co_return, we need to terminate the region similar to return statement. Added a test, and confirms that it now works properly. (without this patch, the statement after the if statement will be treated wrongly) Reviewers: lewissbaker, modocache, junparser Reviewed By: modocache Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82928
2020-03-11Avoid including FileManager.h from SourceManager.hReid Kleckner1-1/+2
Most clients of SourceManager.h need to do things like turning source locations into file & line number pairs, but this doesn't require bringing in FileManager.h and LLVM's FS headers. The main code change here is to sink SM::createFileID into the cpp file. I reason that this is not performance critical because it doesn't happen on the diagnostic path, it happens along the paths of macro expansion (could be hot) and new includes (less hot). Saves some includes: 309 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h 272 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h 271 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h 267 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h 266 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h Differential Revision: https://reviews.llvm.org/D75406
2020-02-28Reland: [Coverage] Revise format to reduce binary sizeVedant Kumar1-55/+79
Try again with an up-to-date version of D69471 (99317124 was a stale revision). --- Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
2020-02-28Revert "[Coverage] Revise format to reduce binary size"Vedant Kumar1-79/+55
This reverts commit 99317124e1c772e9a9de41a0cd56e1db049b4ea4. This is still busted on Windows: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/40873 The llvm-cov tests report 'error: Could not load coverage information'.
2020-02-28[Coverage] Revise format to reduce binary sizeVedant Kumar1-55/+79
Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
2020-01-29[clang] Replace SmallStr.str().str() with std::string conversion operator.Jonas Devlieghere1-1/+1
Use the std::string conversion operator introduced in d7049213d0fcda691c9e79f9b41e357198d99738.
2019-12-04Revert "[Coverage] Revise format to reduce binary size"Vedant Kumar1-79/+55
This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc. On Windows, there is an error: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data
2019-12-04[Coverage] Revise format to reduce binary sizeVedant Kumar1-55/+79
Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
2019-12-03[Coverage] Emit a gap region to cover switch bodiesVedant Kumar1-2/+2
Emit a gap region beginning where the switch body begins. This sets line execution counts in the areas between non-overlapping cases to 0. This also removes some special handling of the first case in a switch: these are now treated like any other case. This does not resolve an outstanding issue with case statement regions that do not end when a region is terminated. But it should address llvm.org/PR44011. Differential Revision: https://reviews.llvm.org/D70571
2019-10-28Revert "Use -fdebug-compilation-dir to form absolute paths in coverage mappings"Reid Kleckner1-18/+7
This reverts commit 9d4806a387892972fd544c0dcaefb0926126220c. There seem to be bugs in llvm-cov --path-equivalence that are causing Chromium problems. Revert this until they are understood or fixed.
2019-10-10Re-land "Use -fdebug-compilation-dir to form absolute paths in coverage ↵Reid Kleckner1-7/+18
mappings" This reverts r374324 (git commit 62808631acceaa8b78f8ab9b407eb6b943ff5f77) I changed the test to not rely on finding the sequence "clang, test, CoverageMapping" in the CWD used to run the test. Instead it makes its own internal directory hierarchy of foo/bar/baz and looks for that. llvm-svn: 374403
2019-10-10Revert "Use -fdebug-compilation-dir to form absolute paths in coverage mappings"Kadir Cetinkaya1-18/+7
This reverts commit f6777964bde28c349d3e289ea37ecf5f5eeedbc4. Because the absolute path check relies on temporary path containing "clang", "test" and "CoverageMapping" as a subsequence, which is not necessarily true on all systems(breaks internal integrates). Wanted to fix it by checking for a leading "/" instead, but then noticed that it would break windows tests, so leaving it to the author instead. llvm-svn: 374324
2019-10-10Use -fdebug-compilation-dir to form absolute paths in coverage mappingsReid Kleckner1-7/+18
This allows users to explicitly request relative paths with `-fdebug-compilation-dir .`. Fixes PR43614 Reviewers: vsk, arphaman Differential Revision: https://reviews.llvm.org/D68733 llvm-svn: 374266
2019-10-03[Alignment][Clang][NFC] Add CharUnits::getAsAlignGuillaume Chatelet1-1/+1
Summary: This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68274 llvm-svn: 373592
2019-07-16Fix parameter name comments using clang-tidy. NFC.Rui Ueyama1-1/+1
This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
2019-06-05Reduce memory consumption of coverage dumpsSerge Guelton1-4/+13
Avoiding an intermediate join operation removes the need for an intermediate buffer that may be quite large, as showcased by https://bugs.llvm.org/show_bug.cgi?id=41965 Differential Revision: https://reviews.llvm.org/D62623 llvm-svn: 362584
2019-04-24Use llvm::stable_sortFangrui Song1-1/+1
llvm-svn: 359098
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-28[Coverage] Do not visit artificial stmts in defaulted methods (PR39822)Vedant Kumar1-4/+16
There is no reason to emit coverage mappings for artificial statements contained within defaulted methods, as these statements are not visible to users. Only emit a mapping for the body of the defaulted method (clang treats the text of the "default" keyword as the body when reporting locations). This allows users to see how often the default method is called, but trims down the coverage mapping by skipping visitation of the children of the method. The immediate motivation for this change is that the lexer's getPreciseTokenLocEnd API cannot return the correct location when given an artificial statement (with a somewhat made-up location) as an input. Test by Orivej Desh! Fixes llvm.org/PR39822. llvm-svn: 347803
2018-11-19[Coverage] Fix PR39258: support coverage regions that start deeper than they endVedant Kumar1-11/+42
popRegions used to assume that the start location of a region can't be nested deeper than the end location, which is not always true. Patch by Orivej Desh! Differential Revision: https://reviews.llvm.org/D53244 llvm-svn: 347262
2018-09-28[cxx2a] P0614R1: Support init-statements in range-based for loops.Richard Smith1-0/+2
We don't yet support this for the case where a range-based for loop is implicitly rewritten to an ObjC for..in statement. llvm-svn: 343350
2018-09-06Remove deprecated APIStephen Kelly1-4/+0
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50353 llvm-svn: 341573
2018-08-09Mark up deprecated methods as suchStephen Kelly1-1/+4
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50352 llvm-svn: 339403
2018-08-09Port getLocEnd -> getEndLocStephen Kelly1-1/+1
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
2018-08-09Port getLocStart -> getBeginLocStephen Kelly1-3/+3
Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
2018-08-09Port getStartLoc -> getBeginLocStephen Kelly1-11/+11
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50349 llvm-svn: 339384
2018-08-09Add getBeginLoc API to replace getStartLocStephen Kelly1-1/+2
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50347 llvm-svn: 339373
2018-06-01[Coverage] End deferred regions before labels, fixes PR35867Vedant Kumar1-0/+1
A deferred region should end before the start of a label, and should not extend to the start of the label sub-statement. Fixes llvm.org/PR35867. llvm-svn: 333715
2018-05-30[Coverage] Discard the last uncompleted deferred region in a declVedant Kumar1-25/+5
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
2018-05-17Support: Add a raw_ostream::write_zeros() function. NFCI.Peter Collingbourne1-2/+1
This will eventually replace MCObjectWriter::WriteZeros. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47033 llvm-svn: 332675
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-41/+41
This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-04-30PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith1-3/+3
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
2018-04-06Fix typos in clangAlexander Kornienko1-1/+1
Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
2018-02-16[Coverage] Handle break/continue outside of loop bodiesVedant Kumar1-8/+16
Teach the coverage mapping logic to handle break or continue statements within for loop increments. Fixes llvm.org/PR36406. llvm-svn: 325319
2018-01-17[Parse] Forward brace locations to TypeConstructExprVedant Kumar1-1/+4
When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
2017-11-29[Coverage] Emit gap areas in braces-optional statements (PR35387)Vedant Kumar1-9/+61
Emit a gap area starting after the r-paren location and ending at the start of the body for the braces-optional statements (for, for-each, while, etc). The count for the gap area equal to the body's count. This extends the fix in r317758. Fixes PR35387, rdar://35570345 Testing: stage2 coverage-enabled build of clang, check-clang llvm-svn: 319373
2017-11-09[Coverage] Emit deferred regions in headersVedant Kumar1-3/+5
There are some limitations with emitting regions in macro expansions because we don't gather file IDs within the expansions. Fix the check that prevents us from emitting deferred regions in expansions to make an exception for headers, which is something we can handle. rdar://35373009 llvm-svn: 317760
2017-11-09[Coverage] Complete top-level deferred regions before labelsVedant Kumar1-3/+38
The area immediately after a terminated region in the function top-level should have the same count as the label it precedes. This solves another problem with wrapped segments. Consider: 1| a: 2| return 0; 3| b: 4| return 1; Without a gap area starting after the first return, the wrapped segment from line 2 would make it look like line 3 is executed, when it's not. rdar://35373009 llvm-svn: 317759
2017-11-09[Coverage] Emit a gap area after if conditionsVedant Kumar1-1/+26
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
2017-10-17[Coverage] Discard deferred region in closing if-elseVedant Kumar1-7/+23
A trailing deferred region isn't necessary in a function that ends with this pattern: ... else { ... return; } Special-case this pattern so that the closing curly brace of the function isn't marked as uncovered. This issue came up in PR34962. llvm-svn: 315982
2017-10-17[Coverage] Explicitly mark the l.h.s of && and || (fixes PR33465)Vedant Kumar1-4/+6
This makes it possible to view sub-line region counts for the l.h.s of && and || expressions in coverage reports. It also fixes PR33465, which shows an example of incorrect coverage output for an assignment statement containing '||'. llvm-svn: 315979
2017-09-19[Coverage] Remove deferred region for trailing return, fixes PR34611Vedant Kumar1-1/+7
As a special case, throw away deferred regions for trailing returns. This allows the closing curly brace to have a count, and is less distracting. llvm-svn: 313603
2017-09-18[Coverage] Use a new API to label gap areasVedant Kumar1-5/+25
This will make it possible for llvm-cov to pick better line execution counts, and is part of the fix for llvm.org/PR34612. llvm-svn: 313598
2017-09-11[Lexer] Report more precise skipped regions (PR34166)Vedant Kumar1-1/+1
This patch teaches the preprocessor to report more precise source ranges for code that is skipped due to conditional directives. The new behavior includes the '#' from the opening directive and the full text of the line containing the closing directive in the skipped area. This matches up clang's behavior (we don't IRGen the code between the closing "endif" and the end of a line). This also affects the code coverage implementation. See llvm.org/PR34166 (this also happens to be rdar://problem/23224058). The old behavior (report the end of the skipped range as the end location of the 'endif' token) is preserved for indexing clients. Differential Revision: https://reviews.llvm.org/D36642 llvm-svn: 312947
2017-09-08[Coverage] Precise region termination with deferred regions (reapply)Vedant Kumar1-5/+86
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
2017-08-08[coverage] Special-case calls to noreturn functions.Eli Friedman1-0/+10
The code after a noreturn call doesn't execute. The pattern in the testcase is pretty common in LLVM (a switch with a default case that calls llvm_unreachable). The original version of this patch was reverted in r309995 due to a crash. This version includes a fix for that crash (testcase in test/CoverageMapping/md.cpp). Differential Revision: https://reviews.llvm.org/D36250 llvm-svn: 310406
2017-08-05Revert "[Coverage] Precise region termination with deferred regions"Vedant Kumar1-86/+5
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
2017-08-04Revert "[coverage] Special-case calls to noreturn functions."Vedant Kumar1-12/+0
This reverts commit r309995. It looks like it's responsible for breaking the stage2 coverage build: http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1402 The cfe-commits discussion re: r309995 has more context. llvm-svn: 310019
2017-08-04[Coverage] Precise region termination with deferred regionsVedant Kumar1-5/+86
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
2017-08-03[coverage] Special-case calls to noreturn functions.Eli Friedman1-0/+12
The code after a noreturn call doesn't execute. The pattern in the testcase is pretty common in LLVM (a switch with a default case that calls llvm_unreachable). Differential Revision: https://reviews.llvm.org/D36250 llvm-svn: 309995
generated by cgit v1.1 at 2025-10-01 21:19:37 +0000