aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Rewrite
AgeCommit message (Collapse)AuthorFilesLines
2025-06-26[clang] NFC: Add alias for std::pair<FileID, unsigned> used in ↵Haojian Wu1-1/+1
SourceLocation (#145711) Introduce a type alias for the commonly used `std::pair<FileID, unsigned>` to improve code readability, and make it easier for future updates (64-bit source locations).
2025-06-15[clang] Remove unused includes (NFC) (#144285)Kazu Hirata1-2/+0
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-05-22Reapply "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Jan Svoboda1-2/+2
(#139584)" This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
2025-05-22Revert "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Kazu Hirata1-2/+2
(#139584)" This reverts commit 9e306ad4600c4d3392c194a8be88919ee758425c. Multiple builtbot failures have been reported: https://github.com/llvm/llvm-project/pull/139584
2025-05-22[clang] Remove intrusive reference count from `DiagnosticOptions` (#139584)Jan Svoboda1-2/+2
The `DiagnosticOptions` class is currently intrusively reference-counted, which makes reasoning about its lifetime very difficult in some cases. For example, `CompilerInvocation` owns the `DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and only exposes an accessor returning `DiagnosticOptions &`. One would think this gives `CompilerInvocation` exclusive ownership of the object, but that's not the case: ```c++ void shareOwnership(CompilerInvocation &CI) { llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions(); // ... } ``` This is a perfectly valid pattern that is being actually used in the codebase. I would like to ensure the ownership of `DiagnosticOptions` by `CompilerInvocation` is guaranteed to be exclusive. This can be leveraged for a copy-on-write optimization later on. This PR changes usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and `lldb` to not be intrusively reference-counted.
2024-08-18[llvm][clang] Move RewriterBuffer to ADT. (#99770)Jacques Pienaar5-1380/+8
These classes are not specific to clang and useful for other rewriter tools (flagged in previous review).
2024-02-01[analyzer][HTMLRewriter] Cache partial rewrite results. (#80220)Artem Dergachev1-19/+116
This is a follow-up for 721dd3bc2 [analyzer] NFC: Don't regenerate duplicate HTML reports. Because HTMLRewriter re-runs the Lexer for syntax highlighting and macro expansion purposes, it may get fairly expensive when the rewriter is invoked multiple times on the same file. In the static analyzer (which uses HTMLRewriter for HTML output mode) we only get away with this because there are usually very few reports emitted per file. But if loud checkers are enabled, such as `webkit.*`, this may explode in complexity and even cause the compiler to run over the 32-bit SourceLocation addressing limit. This patch caches intermediate results so that re-lexing only needed to happen once. As the clever __COUNTER__ test demonstrates, "once" is still too many. Ideally we shouldn't re-lex anything at all, which remains a TODO.
2023-12-13[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)Kazu Hirata1-2/+2
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-05[clang][tidy] Ensure rewriter has the correct CWD (#67839)Jan Svoboda1-6/+7
This patch replaces use of the deprecated `FileEntry::getName()` with `FileEntryRef::getName()`. This means the code now uses the path that was used to register file entry in `SourceManager` instead of the absolute path that happened to be used in the last call to `FileManager::getFile()` some place else. This caused some test failures due to the fact that some paths can be relative and thus rely on the VFS CWD. The CWD can change for each TU, so when we run `clang-tidy` on a compilation database and try to perform all the replacements at the end, relative paths won't resolve the same. This patch takes care to reinstate the correct CWD and make the path reported by `FileEntryRef` absolute before passing it to `llvm::writeToOutput()`.
2023-09-06Partially revert "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"Jan Svoboda1-1/+1
This commit partially reverts ddbcc10b to fix `clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-run-with-database.cpp`.
2023-09-06[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`Jan Svoboda1-1/+1
This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `SourceManager::getFileEntryForID()` with `SourceManager::getFileEntryRefForID()`. This lowers the number of usages of the deprecated `FileEntry::getName()` from 95 to 50.
2023-07-03[Tooling][Rewriter] Remove the redundant AtomicallyMovedFile Implementation.Haojian Wu1-64/+13
Replace it with llvm::writeToOutput. Reviewed By: avl Differential Revision: https://reviews.llvm.org/D153741
2022-08-08[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-2/+2
With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-01-25Add assert on End iteration distance to Rewriter::getRewrittenText.Ashley Hedberg1-0/+1
I currently have code that is crashing in the second std::advance call, and it was not straightforward to identify the problem, as the first line of the stacktrace is in RopePieceBTreeIterator::operator++: ``` *** SIGILL; stack trace: *** PC: clang/include/clang/Rewrite/Core/RewriteRope.h:119 clang::RopePieceBTreeIterator::operator++() ../include/c++/v1/__iterator/advance.h:35 std::__u::__advance<>() ../include/c++/v1/__iterator/advance.h:65 std::__u::advance<>() clang/lib/Rewrite/Rewriter.cpp:228 clang::Rewriter::getRewrittenText() clang/include/clang/Rewrite/Core/Rewriter.h:106 clang::Rewriter::getRewrittenText() ``` Adding an assertion produces a friendlier error message for the caller. Reviewed By: gribozavr2 Differential Revision: https://reviews.llvm.org/D117579
2022-01-09[clang] Use true/false instead of 1/0 (NFC)Kazu Hirata1-1/+1
Identified with modernize-use-bool-literals.
2021-12-09[NFC][clang] Return underlying strings directly instead of OS.str()Logan Smith1-1/+1
This avoids an unnecessary copy required by 'return OS.str()', allowing instead for NRVO or implicit move. The .str() call (which flushes the stream) is no longer required since 65b13610a5226b84889b923bae884ba395ad084d, which made raw_string_ostream unbuffered by default. Differential Revision: https://reviews.llvm.org/D115374
2021-10-21[clang] Use StringRef::contains (NFC)Kazu Hirata1-1/+1
2021-08-02[analyzer] Highlight arrows for currently selected eventValeriy Savchenko1-1/+1
In some cases, when the execution path of the diagnostic goes back and forth, arrows can overlap and create a mess. Dimming arrows that are not relevant at the moment, solves this issue. They are still visible, but don't draw too much attention. Differential Revision: https://reviews.llvm.org/D92928
2021-08-02[analyzer] Add control flow arrows to the analyzer's HTML reportsValeriy Savchenko1-0/+1
This commit adds a very first version of this feature. It is off by default and has to be turned on by checking the corresponding box. For this reason, HTML reports still keep control notes (aka grey bubbles). Further on, we plan on attaching arrows to events and having all arrows not related to a currently selected event barely visible. This will help with reports where control flow goes back and forth (eg in loops). Right now, it can get pretty crammed with all the arrows. Differential Revision: https://reviews.llvm.org/D92639
2021-03-02[clang] DeltaTree::AddDelta - fix "initialization is never read" clang-tidy ↵Simon Pilgrim1-1/+4
warning. NFCI.
2020-10-23SourceManager: Clarify that FileInfo always has a ContentCache, NFCDuncan P. N. Exon Smith1-4/+4
It turns out that `FileInfo` *always* has a ContentCache. Clarify that in the code: - Update the private version of `SourceManager::createFileID` to take a `ContentCache&` instead of `ContentCache*`, and rename it to `createFileIDImpl` for clarity. - Change `FileInfo::getContentCache` to return a reference. Differential Revision: https://reviews.llvm.org/D89554
2020-10-19Lexer: Update the Lexer to use MemoryBufferRef, NFCDuncan P. N. Exon Smith2-3/+3
Update `Lexer` / `Lexer::Lexer` to use `MemoryBufferRef` instead of `MemoryBuffer*`. Callers that were acquiring a `MemoryBuffer*` via `SourceManager::getBuffer` were updated, such that if they checked `Invalid` they use `getBufferOrNone` and otherwise `getBufferOrFake`. Differential Revision: https://reviews.llvm.org/D89398
2020-10-19clang/{Format,Rewrite}: Stop using SourceManager::getBuffer, NFCDuncan P. N. Exon Smith1-9/+9
Update clang/lib/Format and clang/lib/Rewrite to use a `MemoryBufferRef` from `getBufferOrFake` instead of `MemoryBuffer*` from `getBuffer`. No functionality change here, since the call sites weren't checking if the buffer was valid. Differential Revision: https://reviews.llvm.org/D89406
2019-08-15[Rewrite][NFC] Add FIXMEs and tests for RemoveLineIfEmpty bugJoel E. Denny1-0/+11
I'd like to add these comments to warn others of problems I encountered when trying to use `RemoveLineIfEmpty`. I originally tried to fix the problem, but I realized I could implement the functionality more easily and efficiently in my calling code where I can make the simplifying assumption that there are no prior edits to the line from which text is being removed. While I've lost the motivation to write a fix, which doesn't look easy, I figure a warning to others is better than silence. I've added a unit test to demonstrate the problem. I don't know how to mark it as an expected failure, so I just marked it disabled. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D61466 llvm-svn: 369049
2019-07-06[Rewrite] Extend to further accept CharSourceRangeJoel E. Denny1-3/+6
Some Rewrite functions are already overloaded to accept CharSourceRange, and this extends others in the same manner. I'm calling these in code that's not ready to upstream, but I figure they might be useful to others in the meantime. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D61467 llvm-svn: 365258
2019-05-29[analyzer] [NFC] PathDiagnostic: Create PathDiagnosticPopUpPieceCsaba Dabis1-16/+33
Summary: This new piece is similar to our macro expansion printing in HTML reports: On mouse-hover event it pops up on variables. Similar to note pieces it supports `plist` diagnostics as well. It is optional, on by default: `add-pop-up-notes=true`. Extra: In HTML reports `background-color: LemonChiffon` was too light, changed to `PaleGoldenRod`. Reviewers: NoQ, alexfh Reviewed By: NoQ Subscribers: cfe-commits, gerazo, gsd, george.karpenkov, alexfh, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D60670 llvm-svn: 362014
2019-05-17[Lex] Allow to consume tokens while preprocessingIlya Biryukov1-1/+1
Summary: By adding a hook to consume all tokens produced by the preprocessor. The intention of this change is to make it possible to consume the expanded tokens without re-runnig the preprocessor with minimal changes to the preprocessor and minimal performance penalty when preprocessing without recording the tokens. The added hook is very low-level and reconstructing the expanded token stream requires more work in the client code, the actual algorithm to collect the tokens using this hook can be found in the follow-up change. Reviewers: rsmith Reviewed By: rsmith Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59885 llvm-svn: 361007
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth5-20/+15
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-12-10Misc typos fixes in ./lib folderRaphael Isemann1-2/+2
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
2018-11-01Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner1-1/+1
This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
2018-07-30Remove trailing spaceFangrui Song3-6/+6
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-1/+1
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-9/+10
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-03-27[Edit, Rewrite] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko4-83/+97
warnings; other minor fixes (NFC). llvm-svn: 328597
2018-01-23[analyzer] Show full analyzer invocation for reproducibility in HTML reportsGeorge Karpenkov1-0/+20
Analyzing problems which appear in scan-build results can be very difficult, as after the launch no exact invocation is stored, and it's super-hard to launch the debugger. With this patch, the exact analyzer invocation appears in the footer, and can be copied to debug/check reproducibility/etc. rdar://35980230 llvm-svn: 323245
2018-01-23[html] [NFC] Use raw strings to dump the style table.George Karpenkov1-76/+102
llvm-svn: 323244
2018-01-17[analyzer] Better UI in html reports for displaying shortcuts helpGeorge Karpenkov1-0/+4
Make the help window accessible, but don't show by default. Use a different CSS class from macro. llvm-svn: 322750
2018-01-17[analyzer] support a mode to only show relevant lines in HTML diagnosticsGeorge Karpenkov1-4/+7
HTML diagnostics can be an overwhelming blob of pages of code. This patch adds a checkbox which filters this list down to only the lines *relevant* to the counterexample by e.g. skipping branches which analyzer has assumed to be infeasible at a time. The resulting amount of output is much smaller, and often fits on one screen, and also provides a much more readable diagnostics. Differential Revision: https://reviews.llvm.org/D41378 llvm-svn: 322612
2017-12-21[analyzer] Add Javascript to analyzer HTML output to allow keyboard navigation.George Karpenkov1-0/+1
Differential Revision: https://reviews.llvm.org/D41414 llvm-svn: 321320
2017-08-03[Analyzer] Add support for displaying cross-file diagnostic paths in HTML outputDevin Coughlin1-0/+5
This change adds support for cross-file diagnostic paths in html output. If the diagnostic path is not cross-file, there is no change in the output. Patch by Vlad Tsyrklevich! Differential Revision: https://reviews.llvm.org/D30406 llvm-svn: 309968
2017-06-03Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+1
llvm-svn: 304647
2016-10-07[analyzer] Re-apply r283092, attempt no.4, chunk no.4 (last)Artem Dergachev1-2/+7
The problem that caused the msvc crash has been indentified and fixed in the previous commit. This patch contains the rest of r283092. llvm-svn: 283584
2016-10-07Revert "[analyzer] Try to re-apply r283092 "Extend bug reports with extra notes"Artem Dergachev1-7/+2
Vector of smart pointers wasn't the thing that caused msvc crash. llvm-svn: 283537
2016-10-07[analyzer] Try to re-apply r283092 "Extend bug reports with extra notes"Artem Dergachev1-2/+7
Replace SmallVector<IntrusiveRefCntPtr> with a vector of plain pointers. Would insignificantly increase memory usage. llvm-svn: 283536
2016-10-04Revert "[analyzer] Extend bug reports with extra notes" to fix Windows bot.Vitaly Buka1-7/+2
This reverts commit r283092. llvm-svn: 283180
2016-10-03[analyzer] Extend bug reports with extra notesArtem Dergachev1-2/+7
These diagnostics are separate from the path-sensitive engine's path notes, and can be added manually on top of path-sensitive or path-insensitive reports. The new note diagnostics would appear as note:-diagnostic on console and as blue bubbles in scan-build. In plist files they currently do not appear, because format needs to be discussed with plist file users. The analyzer option "-analyzer-config notes-as-events=true" would convert notes to normal path notes, and put them at the beginning of the path. This is a temporary hack to show the new notes in plist files. A few checkers would be updated in subsequent commits, including tests for this new feature. Differential Revision: https://reviews.llvm.org/D24278 llvm-svn: 283092
2016-10-01Use StringRef for MemoryBuffer identifier API (NFC)Mehdi Amini1-3/+3
llvm-svn: 283043
2016-09-15[analyzer] Fix HTMLRewriter style sheets to support non-webkit browsers.Artem Dergachev1-0/+4
This fixes rounded corners and shadows of analyzer diagnostic pieces in browsers such as Firefox. Differential Revision: https://reviews.llvm.org/D23272 llvm-svn: 281625
2016-02-18Remove use of builtin comma operator.Richard Trieu1-2/+4
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261271
2016-02-09Simplify EnterTokenStream API to make it more robust for memory managementDavid Blaikie1-1/+1
While this won't help fix things like the bug that r260219 addressed, it seems like good tidy up to have anyway. (it might be nice if "makeArrayRef" always produced a MutableArrayRef & let it decay to an ArrayRef when needed - then I'd use that for the MutableArrayRefs in this patch) If we had std::dynarray I'd use that instead of unique_ptr+size_t, ideally (but then it'd have to be threaded down through the Preprocessor all the way - no idea how painful that would be) llvm-svn: 260246