summaryrefslogtreecommitdiff
path: root/clang-tools-extra/clang-include-fixer
Commit message (Collapse)AuthorAgeFilesLines
* [include-fixer] Add the missing variant header to the STL header list.Haojian Wu2023-04-131-0/+1
|
* [include-fixer] Add the missing optional header to the STL header list.Haojian Wu2023-03-061-0/+1
|
* [clang-tools-extra] Remove remaining uses of llvm::Optional (NFC)Kazu Hirata2023-01-071-1/+0
| | | | | | | | | | This patch removes the unused "using" declaration and removes #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* [clang-tools-extra] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata2023-01-073-4/+4
| | | | | | | | | | | This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* [clang-tools-extra] Add #include <optional> (NFC)Kazu Hirata2023-01-073-0/+3
| | | | | | | | | | | | | This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* Remove unused #include "llvm/ADT/Optional.h"Fangrui Song2022-12-051-1/+0
|
* [clang-tools-extra] Use std::nullopt instead of None (NFC)Kazu Hirata2022-12-032-5/+6
| | | | | | | | | | | | This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* try to fix build more after 16544cbe64b8Nico Weber2022-09-281-0/+3
|
* [clang-format][NFC] Rewrite prints in python3 compatible wayDanil Sidoruk2022-09-251-3/+3
| | | | | | Closes #55996. Differential Revision: https://reviews.llvm.org/D131789
* [cmake] do not set execution permission to regular files.Sinan Lin2022-09-071-2/+2
| | | | | | | | | | | some regular files(e.g. files have no shebang and no execute bit in source dir) are wrongly assigned an execution permission, such as scanview.css and ear.c from libscanbuild, which is unnecessary and introduces warnings in some envs. Reviewed By: MaskRay, phosek Differential Revision: https://reviews.llvm.org/D133308
* [NFC] Make MultiplexExternalSemaSource own sourcesChris Bieneman2022-09-021-8/+9
| | | | | | | | | | This change refactors the MuiltiplexExternalSemaSource to take ownership of the underlying sources. As a result it makes a larger cleanup of external source ownership in Sema and the ChainedIncludesSource. Reviewed By: aaron.ballman, aprantl Differential Revision: https://reviews.llvm.org/D133158
* LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song2022-08-091-3/+3
|
* [clang] Implement ElaboratedType sugaring for types written bareMatheus Izvekov2022-07-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, clang will not wrap in an ElaboratedType node types written without a keyword and nested name qualifier, which goes against the intent that we should produce an AST which retains enough details to recover how things are written. The lack of this sugar is incompatible with the intent of the type printer default policy, which is to print types as written, but to fall back and print them fully qualified when they are desugared. An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still requires pointer alignment due to pre-existing bug in the TypeLoc buffer handling. --- Troubleshooting list to deal with any breakage seen with this patch: 1) The most likely effect one would see by this patch is a change in how a type is printed. The type printer will, by design and default, print types as written. There are customization options there, but not that many, and they mainly apply to how to print a type that we somehow failed to track how it was written. This patch fixes a problem where we failed to distinguish between a type that was written without any elaborated-type qualifiers, such as a 'struct'/'class' tags and name spacifiers such as 'std::', and one that has been stripped of any 'metadata' that identifies such, the so called canonical types. Example: ``` namespace foo { struct A {}; A a; }; ``` If one were to print the type of `foo::a`, prior to this patch, this would result in `foo::A`. This is how the type printer would have, by default, printed the canonical type of A as well. As soon as you add any name qualifiers to A, the type printer would suddenly start accurately printing the type as written. This patch will make it print it accurately even when written without qualifiers, so we will just print `A` for the initial example, as the user did not really write that `foo::` namespace qualifier. 2) This patch could expose a bug in some AST matcher. Matching types is harder to get right when there is sugar involved. For example, if you want to match a type against being a pointer to some type A, then you have to account for getting a type that is sugar for a pointer to A, or being a pointer to sugar to A, or both! Usually you would get the second part wrong, and this would work for a very simple test where you don't use any name qualifiers, but you would discover is broken when you do. The usual fix is to either use the matcher which strips sugar, which is annoying to use as for example if you match an N level pointer, you have to put N+1 such matchers in there, beginning to end and between all those levels. But in a lot of cases, if the property you want to match is present in the canonical type, it's easier and faster to just match on that... This goes with what is said in 1), if you want to match against the name of a type, and you want the name string to be something stable, perhaps matching on the name of the canonical type is the better choice. 3) This patch could expose a bug in how you get the source range of some TypeLoc. For some reason, a lot of code is using getLocalSourceRange(), which only looks at the given TypeLoc node. This patch introduces a new, and more common TypeLoc node which contains no source locations on itself. This is not an inovation here, and some other, more rare TypeLoc nodes could also have this property, but if you use getLocalSourceRange on them, it's not going to return any valid locations, because it doesn't have any. The right fix here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive into the inner TypeLoc to get the source range if it doesn't find it on the top level one. You can use getLocalSourceRange if you are really into micro-optimizations and you have some outside knowledge that the TypeLocs you are dealing with will always include some source location. 4) Exposed a bug somewhere in the use of the normal clang type class API, where you have some type, you want to see if that type is some particular kind, you try a `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match. Again, like 2), this would usually have been tested poorly with some simple tests with no qualifications, and would have been broken had there been any other kind of type sugar, be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType. The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper into the type. Or use `getAsAdjusted` when dealing with TypeLocs. For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast. 5) It could be a bug in this patch perhaps. Let me know if you need any help! Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D112374
* Use llvm::sort instead of std::sort where possibleDmitri Gribenko2022-07-231-6/+6
| | | | | | | | | | | llvm::sort is beneficial even when we use the iterator-based overload, since it can optionally shuffle the elements (to detect non-determinism). However llvm::sort is not usable everywhere, for example, in compiler-rt. Reviewed By: nhaehnle Differential Revision: https://reviews.llvm.org/D130406
* Use the range-based overload of llvm::sort where possibleDmitri Gribenko2022-07-231-1/+1
| | | | | | Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D130403
* Revert "[clang] Implement ElaboratedType sugaring for types written bare"Jonas Devlieghere2022-07-141-2/+1
| | | | | | | This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because it stills breaks the LLDB tests. This was re-landed without addressing the issue or even agreement on how to address the issue. More details and discussion in https://reviews.llvm.org/D112374.
* [clang] Implement ElaboratedType sugaring for types written bareMatheus Izvekov2022-07-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, clang will not wrap in an ElaboratedType node types written without a keyword and nested name qualifier, which goes against the intent that we should produce an AST which retains enough details to recover how things are written. The lack of this sugar is incompatible with the intent of the type printer default policy, which is to print types as written, but to fall back and print them fully qualified when they are desugared. An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still requires pointer alignment due to pre-existing bug in the TypeLoc buffer handling. --- Troubleshooting list to deal with any breakage seen with this patch: 1) The most likely effect one would see by this patch is a change in how a type is printed. The type printer will, by design and default, print types as written. There are customization options there, but not that many, and they mainly apply to how to print a type that we somehow failed to track how it was written. This patch fixes a problem where we failed to distinguish between a type that was written without any elaborated-type qualifiers, such as a 'struct'/'class' tags and name spacifiers such as 'std::', and one that has been stripped of any 'metadata' that identifies such, the so called canonical types. Example: ``` namespace foo { struct A {}; A a; }; ``` If one were to print the type of `foo::a`, prior to this patch, this would result in `foo::A`. This is how the type printer would have, by default, printed the canonical type of A as well. As soon as you add any name qualifiers to A, the type printer would suddenly start accurately printing the type as written. This patch will make it print it accurately even when written without qualifiers, so we will just print `A` for the initial example, as the user did not really write that `foo::` namespace qualifier. 2) This patch could expose a bug in some AST matcher. Matching types is harder to get right when there is sugar involved. For example, if you want to match a type against being a pointer to some type A, then you have to account for getting a type that is sugar for a pointer to A, or being a pointer to sugar to A, or both! Usually you would get the second part wrong, and this would work for a very simple test where you don't use any name qualifiers, but you would discover is broken when you do. The usual fix is to either use the matcher which strips sugar, which is annoying to use as for example if you match an N level pointer, you have to put N+1 such matchers in there, beginning to end and between all those levels. But in a lot of cases, if the property you want to match is present in the canonical type, it's easier and faster to just match on that... This goes with what is said in 1), if you want to match against the name of a type, and you want the name string to be something stable, perhaps matching on the name of the canonical type is the better choice. 3) This patch could exposed a bug in how you get the source range of some TypeLoc. For some reason, a lot of code is using getLocalSourceRange(), which only looks at the given TypeLoc node. This patch introduces a new, and more common TypeLoc node which contains no source locations on itself. This is not an inovation here, and some other, more rare TypeLoc nodes could also have this property, but if you use getLocalSourceRange on them, it's not going to return any valid locations, because it doesn't have any. The right fix here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive into the inner TypeLoc to get the source range if it doesn't find it on the top level one. You can use getLocalSourceRange if you are really into micro-optimizations and you have some outside knowledge that the TypeLocs you are dealing with will always include some source location. 4) Exposed a bug somewhere in the use of the normal clang type class API, where you have some type, you want to see if that type is some particular kind, you try a `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match. Again, like 2), this would usually have been tested poorly with some simple tests with no qualifications, and would have been broken had there been any other kind of type sugar, be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType. The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper into the type. Or use `getAsAdjusted` when dealing with TypeLocs. For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast. 5) It could be a bug in this patch perhaps. Let me know if you need any help! Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D112374
* Revert "[clang] Implement ElaboratedType sugaring for types written bare"Jonas Devlieghere2022-07-131-2/+1
| | | | | | | | | | | | | | | | | | | | | This reverts commit bdc6974f92304f4ed542241b9b89ba58ba6b20aa because it breaks all the LLDB tests that import the std module. import-std-module/array.TestArrayFromStdModule.py import-std-module/deque-basic.TestDequeFromStdModule.py import-std-module/deque-dbg-info-content.TestDbgInfoContentDequeFromStdModule.py import-std-module/forward_list.TestForwardListFromStdModule.py import-std-module/forward_list-dbg-info-content.TestDbgInfoContentForwardListFromStdModule.py import-std-module/list.TestListFromStdModule.py import-std-module/list-dbg-info-content.TestDbgInfoContentListFromStdModule.py import-std-module/queue.TestQueueFromStdModule.py import-std-module/stack.TestStackFromStdModule.py import-std-module/vector.TestVectorFromStdModule.py import-std-module/vector-bool.TestVectorBoolFromStdModule.py import-std-module/vector-dbg-info-content.TestDbgInfoContentVectorFromStdModule.py import-std-module/vector-of-vectors.TestVectorOfVectorsFromStdModule.py https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45301/
* [clang] Implement ElaboratedType sugaring for types written bareMatheus Izvekov2022-07-131-1/+2
| | | | | | | | | | | | | | | | | | | Without this patch, clang will not wrap in an ElaboratedType node types written without a keyword and nested name qualifier, which goes against the intent that we should produce an AST which retains enough details to recover how things are written. The lack of this sugar is incompatible with the intent of the type printer default policy, which is to print types as written, but to fall back and print them fully qualified when they are desugared. An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still requires pointer alignment due to pre-existing bug in the TypeLoc buffer handling. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D112374
* [clang-tools-extra][cmake] Use `GNUInstallDirs` to support custom ↵John Ericson2022-01-222-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | installation dirs. This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
* Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson2022-01-162-3/+3
| | | | | | | | https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have this odd error, not sure how to reproduce, so I will just try breaking up my patch. This reverts commit 4a678f8072004eff9214c1a4e1836a14abb69535.
* [cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson2022-01-162-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
* Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson2022-01-152-3/+3
| | | | | | Sorry for the disruption, I will try again later. This reverts commit efeb50197091b2ade24c00b9d55814bc433a7fd1.
* [cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson2022-01-152-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
* [clang-tools-extra] Remove unused using (NFC)Kazu Hirata2021-12-312-3/+0
| | | | Identified by misc-unused-using-decls.
* [clang-include-fixer] Fix incorrect ranking because of dangling referencesDanila Kutenin2021-12-201-10/+11
| | | | | | | | | | | | | | | | | | SymbolAndSignals stores SymbolInfo which stores two std::strings. Then the values are stored in a llvm::DenseMap<llvm::StringRef, double>. When the sorting is happening, SymbolAndSignals are swapped and thus because of small string optimization some strings may become invalid. This results in incorrect ranking. This was detected when running new std::sort algorithm against llvm toolchain. This could have been prevented with running llvm::sort and EXPENSIVE_CHECKS. Unfortunately, no sanitizer yelled. I don't have commit rights, kutdanila@yandex.ru Danila Kutenin Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D116037
* Cleanup identifier parsing; NFCCorentin Jabot2021-09-141-1/+1
| | | | | | Rename methods to clearly signal when they only deal with ASCII, simplify the parsing of identifier, and use start/continue instead of head/body for consistency with Unicode terminology.
* [clang-include-fixer] Pre-reserve vector size. NFCSam McCall2021-02-031-0/+1
|
* [clang-tooling] Prevent llvm::fatal_error on invalid CLI optionserge-sans-paille2021-01-292-2/+15
| | | | | | | Fail gracefully instead. Prevent further misuse by enforcing the factory builder instead of the constructor. Differential Revision: https://reviews.llvm.org/D94420
* [clang][nearly-NFC] Remove some superfluous uses of NamedDecl::getNameAsStringBruno Ricci2020-08-051-1/+1
| | | | | | | | | `OS << ND->getDeclName();` is equivalent to `OS << ND->getNameAsString();` without the extra temporary string. This is not quite a NFC since two uses of `getNameAsString` in a diagnostic are replaced, which results in the named entity being quoted with additional "'"s (ie: 'var' instead of var).
* [openmp] Add missing dependencies for OMP.h.inc after d90443bValentin Clement2020-06-233-0/+9
|
* [clang-tools-extra] Prevent linking to duplicate .a libs and dylibMichał Górny2020-06-172-2/+8
| | | | | | | | Fix various tool libraries not to link to clang's .a libraries and dylib simultaneously. This may cause breakage, in particular through duplicate command-line option declarations. Differential Revision: https://reviews.llvm.org/D81967
* [OpenMP] "UnFix" layering problem with FrontendOpenMPJohannes Doerfert2020-04-071-0/+1
| | | | | | | | | | | | | | | | This reverts commit 97aa593a8387586095b7eac12974ba2fdd08f4c3 as it causes problems (PR45453) https://reviews.llvm.org/D77574#1966321. This additionally adds an explicit reference to FrontendOpenMP to clang-tidy where ASTMatchers is used. This is hopefully just a temporary solution. The dependence on `FrontendOpenMP` from `ASTMatchers` should be handled by CMake implicitly, not us explicitly. Reviewed By: aheejin Differential Revision: https://reviews.llvm.org/D77666
* Remove llvm::Error include form Diagnostic.hReid Kleckner2020-04-061-0/+1
| | | | | | | | | | | | | | | | | Saves ~400 related LLVM ADT. llvm/ADT/Error.h takes 90ms to parse. $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 403 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Error.h 403 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm-c/Error.h 397 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Format.h 397 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Debug.h 377 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/StringExtras.h 158 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm-c/ExternC.h 138 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/ErrorOr.h 13 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/raw_ostream.h 13 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallString.h 5 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/Twine.h
* [clang-tools-extra] NFC: Fix trivial typo in documents and commentsKazuaki Ishizaki2020-04-056-6/+6
| | | | Differential Revision: https://reviews.llvm.org/D77458
* Avoid including FileManager.h from SourceManager.hReid Kleckner2020-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | 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
* Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer2020-01-289-13/+19
| | | | | | | | | | 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.
* NFC: Fix trivial typos in commentsKazuaki Ishizaki2020-01-042-3/+3
|
* Fix compatibility with python3 of clang-include-fixer.pyYannick Brehon2019-12-031-1/+1
| | | | | | | clang-include-fixer was recently updated to be python3-compatible. However, an exception handling clause was improperly using the deprecated `message` property of Exception classes, so the code was not yet entirely python3-compatible. Differential Revision: https://reviews.llvm.org/D70902
* [include-fixer] Python 3 support for clang-include-fixer.pyBenjamin Kramer2019-11-281-8/+10
| | | | Patch by Yannick Brehon!
* [clang-include-fixer] Suppress cmd prompt from Vim on WindowsReid Kleckner2019-11-221-1/+8
| | | | | | | | Copied from the clang-format.py editor integration. Reviewers: bkramer Differential Revision: https://reviews.llvm.org/D70518
* [clang-include-fixer] Skip .rc files when finding symbolsReid Kleckner2019-11-141-0/+3
| | | | | | | | | | | | | | | | Summary: For some reason CMake includes entries for .rc files, but find-all-symbols handles them improperly. See PR43993 Reviewers: sammccall, bkramer Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70196
* [clang-tools-extra] [cmake] Link against libclang-cpp whenever possibleMichal Gorny2019-10-042-3/+9
| | | | | | | | | Use clang_target_link_libraries() in order to support linking against libclang-cpp instead of static libraries. Differential Revision: https://reviews.llvm.org/D68448 llvm-svn: 373786
* [clang-tools-extra] [cmake] Use add_clang_tool() to install toolsMichal Gorny2019-10-042-7/+1
| | | | | | | | | | | | Replace add_clang_executable() calls with add_clang_tool() that takes care of creating correct, distribution-friendly install target. While at it, remove redundant install calls. This change also causes clang-move and pp-trace to be installed. Differential Revision: https://reviews.llvm.org/D68423 llvm-svn: 373694
* Changed FrontendActionFactory::create to return a std::unique_ptrDmitri Gribenko2019-08-291-2/+2
| | | | | | | | | | Subscribers: jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66947 llvm-svn: 370379
* Remove \brief commands from doxygen comments.Dmitri Gribenko2019-08-228-37/+37
| | | | | | | | | | | | | | | | | | | | | | | Summary: 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 [This is analogous to LLVM r331272 and CFE r331834] Subscribers: srhines, nemanjai, javed.absar, kbarton, MaskRay, jkorous, arphaman, jfb, kadircet, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66578 llvm-svn: 369643
* [clang-tools-extra] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-146-8/+8
| | | | | | | | | | 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: 368944
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [clang-tools-extra] Adopt FileManager's error-returning APIsHarlan Haskins2019-08-011-3/+2
| | | | | | | | The FileManager has been updated to return llvm::ErrorOr from getFile and getDirectory, this commit updates all the callers of those APIs from clang. llvm-svn: 367617
* [clang][HeaderSearch] Shorten paths for includes in mainfile's directoryKadir Cetinkaya2019-07-031-2/+2
| | | | | | | | | | | | | | | | | | Summary: Currently HeaderSearch only looks at SearchDir's passed into it, but in addition to those paths headers can be relative to including file's directory. This patch makes sure that is taken into account. Reviewers: gribozavr Subscribers: jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63295 llvm-svn: 365005
View Lorry Controller Status