aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Tooling/CompilationDatabase.cpp
AgeCommit message (Collapse)AuthorFilesLines
45 hoursNFC: Clean up of IntrusiveRefCntPtr construction from raw pointers. (#151545)James Y Knight1-3/+2
Handles clang::DiagnosticsEngine and clang::DiagnosticIDs. For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to convenience method `DiagnosticIDs::create()`. Part of cleanup https://github.com/llvm/llvm-project/issues/151026
2025-05-31[Tooling] Remove unused includes (NFC) (#142257)Kazu Hirata1-6/+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-4/+4
(#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-4/+4
(#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-4/+4
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-01-20[clang] Use SmallString::operator std::string (NFC)Kazu Hirata1-1/+1
2024-01-19[Tooling] Fix FixedCompilationDatabase with header compile flags (#73913)Sam McCall1-1/+3
Summary: The logic to strip positional args feels very fragile, but it's terribly useful when you want to use a tool on a file and have the exact argv. Today doesn't work with header-parsing actions because these are "precompile" rather than "compile", from tooling's perspective it's all the same. Reviewers: kadircet Subscribers:
2023-12-13[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)Kazu Hirata1-1/+1
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-02-10[NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott1-1/+1
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
2021-01-07[CompilationDatabase] Pass Twine by const reference instead of by value. NFCI.Simon Pilgrim1-3/+3
2020-12-07Add ability to load a FixedCompilationDatabase from a buffer.Sam McCall1-4/+12
Previously, loading one from a file meant allowing the library to do the IO. Clangd would prefer to do such IO itself (e.g. to allow caching). Differential Revision: https://reviews.llvm.org/D92640
2020-11-14[NFC] Small refactor to CompilationDatabaseNathan James1-27/+9
2020-06-19[NFC] Refactor Registry loops to range forNathan James1-6/+4
2020-05-19[Tooling] Drop leading/trailing whitespace from compile_flags.txt linesSam McCall1-2/+8
Summary: These files tend to be hand-authored, and people get very confused. I can't think of any reason that such whitespace would be intended. Reviewers: kadircet Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80160
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-4/+4
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-2/+2
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
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
2019-01-16Reapply [Tooling] Make clang-tool find libc++ dir on mac when running on a ↵Sam McCall1-4/+15
file without compilation database. This reverts commit r351282, and re-lands r351222 and r351229 with the use-after-free fixed. llvm-svn: 351316
2019-01-16Revert "[Tooling] Make clang-tool find libc++ dir on mac when running on a ↵Vlad Tsyrklevich1-14/+4
file without compilation database." This reverts commits r351222 and r351229, they were causing ASan/MSan failures on the sanitizer bots. llvm-svn: 351282
2019-01-15[Tooling] Make clang-tool find libc++ dir on mac when running on a file ↵Haojian Wu1-4/+14
without compilation database. Summary: This is a regression of r348365. When clang-tools run on a file without a complation database (`clang-check /tmp/t.cc`), we will use fixed compilation database as a fallback. However the actual compiler path in the fallback complation command is just `clang-tool` which is insufficient to detect the libc++ dir. Reviewers: ilya-biryukov, EricWF Reviewed By: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56680 llvm-svn: 351222
2018-08-22[Tooling] Allow -flto flags and filter out -Wa, flagsChih-Hung Hsieh1-6/+14
This change fixes the problem in https://bugs.llvm.org/show_bug.cgi?id=38332 by allowing driver::Action::BackendJobClass to run with the analyzer. Otherwise, such jobs will look up the non-existing compilation database and then run without flags. Also filter out the -Wa,* flags that could be passed to and ignored by the clang compiler. Clang-tidy gives warnings about unused -Wa,* flags. Differential Revision: http://reviews.llvm.org/D51002 llvm-svn: 340421
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-03-14[Tooling] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-16/+39
other minor fixes (NFC). llvm-svn: 327573
2017-11-24[Tooling] Acknowledge that many CompilationDatabases don't support enumeration.Sam McCall1-10/+9
Summary: Provide default implementations so that only getCompileCommands() is mandatory. Reviewers: ioeric Subscribers: cfe-commits, bkramer, klimek Differential Revision: https://reviews.llvm.org/D40409 llvm-svn: 318943
2017-11-09[Tooling] Use FixedCompilationDatabase when `compile_flags.txt` is found.Sam McCall1-2/+36
Summary: This is an alternative to JSONCompilationDatabase for simple projects that don't use a build system such as CMake. (You can also drop one in ~, to make your tools use e.g. C++11 by default) There's no facility for varying flags per-source-file or per-machine. Possibly this could be accommodated backwards-compatibly using cpp, but even if not the simplicity seems worthwhile for the cases that are addressed. Tested with clangd, works great! (requires clangd restart) Reviewers: klimek Subscribers: ilya-biryukov, cfe-commits Differential Revision: https://reviews.llvm.org/D39799 llvm-svn: 317777
2017-10-11Revert "[ADT] Make Twine's copy constructor private."Zachary Turner1-3/+3
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5. This is failing due to some code that isn't built on MSVC so I didn't catch. Not immediately obvious how to fix this at first glance, so I'm reverting for now. llvm-svn: 315536
2017-10-11[ADT] Make Twine's copy constructor private.Zachary Turner1-3/+3
There's a lot of misuse of Twine scattered around LLVM. This ranges in severity from benign (returning a Twine from a function by value that is just a string literal) to pretty sketchy (storing a Twine by value in a class). While there are some uses for copying Twines, most of the very compelling ones are confined to the Twine class implementation itself, and other uses are either dubious or easily worked around. This patch makes Twine's copy constructor private, and fixes up all callsites. Differential Revision: https://reviews.llvm.org/D38767 llvm-svn: 315530
2017-06-29[Tooling] FixedCompilationDatabase should be able to strip positionalAlex Lorenz1-3/+5
arguments when `-fsyntax-only` is used Previously, Clang failed to create a fixed compilation database when the compilation arguments use -fsyntax-only instead of -c. This commit fixes the issue by forcing Clang to look at the compilation job when stripping the positional arguments. Differential Revision: https://reviews.llvm.org/D34687 llvm-svn: 306659
2017-05-24Method loadFromCommandLine should be able to report errorsSerge Pavlov1-16/+26
Now FixedCompilationDatabase::loadFromCommandLine has no means to report which error occurred if it fails to create compilation object. This is a block for implementing D33013, because after that change driver will refuse to create compilation if command line contains erroneous options. This change adds additional argument to loadFromCommandLine, which is assigned error message text if compilation object was not created. This is the same way as other methods of CompilationDatabase report failure. Differential Revision: https://reviews.llvm.org/D33272 llvm-svn: 303741
2016-12-01Extend CompilationDatabase by a field for the output filenameJoerg Sonnenberger1-1/+2
In bigger projects like an Operating System, the same source code is often compiled in slightly different ways. This could be the difference between PIC and non-PIC code for static vs dynamic libraries, it could also be the difference between size optimised versions of tools for ramdisk images. At the moment, the compilation database has no way to distinguish such cases. As first step, add a field in the JSON format for it and process it accordingly. Differential Revision: https://reviews.llvm.org/D27138 llvm-svn: 288436
2016-10-06Use llvm::raw_string_ostream instead of std::stringstream (NFC)Mehdi Amini1-3/+2
As a side effect, this avoid having to call .data() on the StringRef. llvm-svn: 283416
2016-10-01Use StringRef in Registry API (NFC)Mehdi Amini1-1/+1
llvm-svn: 283039
2016-08-05Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn1-0/+2
a registry" This differs from the previous version by being more careful about template instantiation/specialization in order to prevent errors when building with clang -Werror. Specifically: * begin is not defined in the template and is instead instantiated when Head is. I think the warning when we don't do that is wrong (PR28815) but for now at least do it this way to avoid the warning. * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY instead provide a template definition then do explicit instantiation. No compiler I've tried has problems with doing it the other way, but strictly speaking it's not permitted by the C++ standard so better safe than sorry. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 277806
2016-07-28Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn1-2/+0
registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. llvm-svn: 277008
2016-07-28Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn1-0/+2
a registry" This version has two fixes compared to the original: * In Registry.h the template static members are instantiated before they are used, as clang gives an error if you do it the other way around. * The use of the Registry template in clang-tidy is updated in the same way as has been done everywhere else. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 276973
2016-07-27Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn1-2/+0
registry" This is causing a huge pile of buildbot failures. llvm-svn: 276857
2016-07-27Adjust Registry interface to not require plugins to export a registryJohn Brawn1-0/+2
Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. Differential Revision: http://reviews.llvm.org/D21385 llvm-svn: 276856
2016-02-23Rename Action::begin() to Action::input_begin().Nico Weber1-3/+2
Also introduce inputs() that reutnrs an llvm::iterator_range. Iterating over A->inputs() is much less mysterious than iterating over *A. No intended behavior change. llvm-svn: 261674
2015-10-20Roll-back r250822.Angel Garcia Gomez1-2/+2
Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
2015-10-20Apply modernize-use-default to clang.Angel Garcia Gomez1-2/+2
Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
2015-09-11[tooling] In CompileCommand, Expose the 'file' that was associated with the ↵Argyrios Kyrtzidis1-1/+3
command. llvm-svn: 247468
2015-08-07Use LLVM_ATTRIBUTE_UNUSED to hide gcc 5.1 unused variable warning.Yaron Keren1-1/+1
Suggestion by David Blaikie! llvm-svn: 244326
2015-08-07Silence tools/clang/lib/Tooling/CompilationDatabase.cpp:328:12: warning:Yaron Keren1-1/+1
‘clang::tooling::JSONAnchorDest’ defined but not used [-Wunused-variable] from gcc 5.1. llvm-svn: 244312
2015-07-02Driver: Remove the Job class. NFCJustin Bogner1-8/+5
We had a strange relationship here where we made a list of Jobs inherit from a single Job, but there weren't actually any places where this arbitrary nesting was used or needed. Simplify all of this by removing Job entirely and updating all of the users to either work with a JobList or a single Command. llvm-svn: 241310
2015-05-29Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer1-2/+1
If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238601
2015-04-17Improve const-nessDavid Blaikie1-5/+3
This allows callers to pass a char ** (such as the one coming from the standard decreed main declaration - even though everyone usually puts const on that themselves). llvm-svn: 235150
2015-04-11Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko1-2/+2
Summary: The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix Reviewers: dblaikie Reviewed By: dblaikie Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D8926 llvm-svn: 234678
2015-03-09Tooling: Hide implementation detailsBenjamin Kramer1-3/+7
NFC. llvm-svn: 231656
2014-10-03Driver: Use pointee_iterator rather than iterating over unique_ptrsJustin Bogner1-4/+3
There's probably never a good reason to iterate over unique_ptrs. This lets us use range-for and say Job.foo instead of (*it)->foo in a few places. llvm-svn: 218938
2014-09-04unique_ptrify JobList::JobsDavid Blaikie1-3/+3
llvm-svn: 217168
generated by cgit v1.1 at 2025-08-02 16:06:33 +0000