search for: compile_command

I tried running all the commands in the compile_commands.json (thanks for pointing that out), but it runs into the same "No such file or directory: *.inc". I don't see those files built anywhere in that list. Does it take tblgen into account? Doug On Thu, Aug 16, 2018, 1:02 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote:...

Hello, I started using clangd to get better static analysis and code refactoring tooling with the R sources (using eglot-mode in Emacs, it just works once you've generated a `compile_commands.json` file with `bear make all`). I noticed that the static analyser can't understand several header files because these are not self-contained. So I went through all .h files and inserted the missing includes, cf the attached patch. Making the headers self-contained has consequences for the...

...if that makes sense. Best, Lionel On 3/16/23, Lionel Henry <lionel at posit.co> wrote: > Hello, > > I started using clangd to get better static analysis and code > refactoring tooling with the R sources (using eglot-mode in Emacs, it > just works once you've generated a `compile_commands.json` file with > `bear make all`). I noticed that the static analyser can't understand > several header files because these are not self-contained. So I went > through all .h files and inserted the missing includes, cf the > attached patch. > > Making the headers self-contai...

...Test.cpp 2.46 1.79 -27.0% unittests/CodeGen/CodeGenExternalTest.cpp 3.43 2.52 -26.5% tools/libclang/CXStoredDiagnostic.cpp 1.67 1.26 -24.8% tools/clang-func-mapping/ClangFnMapGen.cpp 2.48 1.89 -23.8% Full list: The corresponding patches (careful, they are big): Methodology My tool took the compile_commands.json from LLVM build and iterated over files trying to remove redundant headers. To find which header files could be removed it scanned the file for "#include" lines and tried to remove them one by one (checking if the file still compiles after the removal). When there were no more incl...

...gt; tools/clang-func-mapping/ClangFnMapGen.cpp 2.48 1.89 -23.8% > > Full list: > <clang.txt> > > The corresponding patches (careful, they are big): > <llvm_redundant_headers.patch> > <clang_redundant_headers.patch> > > *Methodology* > My tool took the compile_commands.json from LLVM build and iterated over > files trying to remove redundant headers. To find which header files could > be removed it scanned the file for "#include" lines and tried to remove > them one by one (checking if the file still compiles after the removal). > When the...

...required to execute the tests, >> as it goes through a CMake invocation. >> This issue has a workaround: ninja can be launched directly from >> “runtimes/runtime-bins”, but that is counterintuitive. >> >> 6) Recursive invocation required for “runtimes” breaks >> `compile_commands.json` construction, which is used >> by many editors and tools (e.g. Vim+Ale or rtags) for go-to-defintion and >> error highlight functionality. >> There is a workaround: a separate `compile_commands.json` is generated >> for the `runtimes` directory, >> and it might...

...show the commands > required to execute the tests, > as it goes through a CMake invocation. > This issue has a workaround: ninja can be launched directly from > “runtimes/runtime-bins”, but that is counterintuitive. > > 6) Recursive invocation required for “runtimes” breaks > `compile_commands.json` construction, which is used > by many editors and tools (e.g. Vim+Ale or rtags) for go-to-defintion and > error highlight functionality. > There is a workaround: a separate `compile_commands.json` is generated for > the `runtimes` directory, > and it might be possible to write...

...tests, >>> as it goes through a CMake invocation. >>> This issue has a workaround: ninja can be launched directly from >>> “runtimes/runtime-bins”, but that is counterintuitive. >>> >>> 6) Recursive invocation required for “runtimes” breaks >>> `compile_commands.json` construction, which is used >>> by many editors and tools (e.g. Vim+Ale or rtags) for go-to-defintion >>> and error highlight functionality. >>> There is a workaround: a separate `compile_commands.json` is generated >>> for the `runtimes` directory, >&g...

...-mapping/ClangFnMapGen.cpp 2.48 1.89 -23.8% > > Full list: > > <clang.txt> > > > The corresponding patches (careful, they are big): > > <llvm_redundant_headers.patch> > <clang_redundant_headers.patch> > > > *Methodology* > My tool took the compile_commands.json from LLVM build and iterated over > files trying to remove redundant headers. To find which header files could > be removed it scanned the file for "#include" lines and tried to remove > them one by one (checking if the file still compiles after the removal). > When the...

This is a recent desktop. Xubuntu 19.10 Compiling for 10.0.0 clang and llvm. See below. For this test, running 14 processors in a gui VM. The cores are hyperthreaded, processors are twice the cores, but all the cores before the run are showing negligible activity. compile_commands.json has 3022 entries. The ninja compile run lasted 7 minutes and 43 seconds with 99% all processor usage throughout. We then have 7*60+43 = 463 seconds. Compile seconds per compile line in compile_commands.json 463/3022 = 0.1532 seconds. Average compile time per processor would be about 14*...

...() from the opt tool, so any command line arguments (passes with legacy or new passmanager, cl::opt options, etc.) can be passed. It also makes converting existing tests simpler. The top-level structure is C++ (i.e. the LLVM-IR is removed by the preprocessor) and compiled with cmake. This allows a compile_commands.json to be created such that refactoring tools, clang-tidy, and clang-format can easily be applied on the code. The second argument to run_opt is the preprocessor directive for the IR such that multiple IR modules can be embedded into the file. Such tests can be compiled in two modes: Either with...

...as it goes through a CMake invocation. >>>> This issue has a workaround: ninja can be launched directly from >>>> “runtimes/runtime-bins”, but that is counterintuitive. >>>> >>>> 6) Recursive invocation required for “runtimes” breaks >>>> `compile_commands.json` construction, which is used >>>> by many editors and tools (e.g. Vim+Ale or rtags) for go-to-defintion >>>> and error highlight functionality. >>>> There is a workaround: a separate `compile_commands.json` is generated >>>> for the `runtimes` d...

...// RUN: echo 'int *HP = 0;' > %T/compilation-database-test/include/header.h // RUN: echo '#include "header.h"' > %T/compilation-database-test/b/d.cpp // RUN: sed 's|test_dir|%T/compilation-database-test|g' %S/Inputs/compilation-database/template.json > %T/compile_commands.json // RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %T/compilation-database-test/b/not-exist -header-filter=.* // RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %T/compilation-database-test/a/a.cpp %T/compilation-database-test/a/b.cpp %T/compilation-database-test/b/b.cpp %T/co...

...cute the tests, >>>> as it goes through a CMake invocation. >>>> This issue has a workaround: ninja can be launched directly from “runtimes/runtime-bins”, but that is counterintuitive. >>>> >>>> 6) Recursive invocation required for “runtimes” breaks `compile_commands.json` construction, which is used >>>> by many editors and tools (e.g. Vim+Ale or rtags) for go-to-defintion and error highlight functionality. >>>> There is a workaround: a separate `compile_commands.json` is generated for the `runtimes` directory, >>>> and it...

Hello, I'm trying to use the python libclang bindings to write a C++ style-checker, and I'd like to detect all the typedefs to recommend switching to using. I'm using libclang 3.8, with the python bindings provided with it. When I parse a file with index = clang.cindex.Index.create() tu = index.parse(f, ['-x', 'c++', '-std=c++11', '-fsyntax-only',

...t; t/clang-tidy/Output/run-clang-tidy.cpp.tmp/test.cpp\"}]" | sed -e > 's/\\/\\\\/g' > > /home/nnelson/Documents/llvm-project/llvm/utils/release/rc4/Phase3/Release+Asserts/llvmCore-9.0.0-rc4.obj/tools/clang/too > ls/extra/test/clang-tidy/Output/run-clang-tidy.cpp.tmp/compile_commands.json > : 'RUN: at line 5';   echo "Checks: '-*,modernize-use-auto'" > > /home/nnelson/Documents/llvm-project/llvm/utils/release/rc4/Phase3/Release+Asserts/llvmCore-9.0.0-rc4.obj/tools/clang/tools/extra/test/clang > -tidy/Output/run-clang-tidy.cpp.tmp/.clang-t...

...;> Full list: >> >> <clang.txt> >> >> >> The corresponding patches (careful, they are big): >> >> <llvm_redundant_headers.patch> >> <clang_redundant_headers.patch> >> >> >> *Methodology* >> My tool took the compile_commands.json from LLVM build and iterated over >> files trying to remove redundant headers. To find which header files could >> be removed it scanned the file for "#include" lines and tried to remove >> them one by one (checking if the file still compiles after the removal). &...

On Sat, Feb 29, 2020 at 5:14 PM Nicholas Krause via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2/29/20 7:23 PM, River Riddle wrote: > > > > On Sat, Feb 29, 2020 at 4:00 PM Nicholas Krause <xerofoify at gmail.com> > wrote: > >> >> >> On 2/29/20 6:17 PM, River Riddle via llvm-dev wrote: >> >> >> >> On Sat,

Thanks! I'll get this posted on the web site. The "Performing Test ... failed to compile" failures from cmake are not interesting. But could you look in the log file and try to see what were the tests that failed in the "check-all" step? On Thu, Sep 12, 2019 at 4:39 PM Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Xubuntu/Ubuntu 19.04,

...We have a merge-based flow rather than continually rebasing our patch set, but it went reasonably smoothly nevertheless. The one snag I hit is that the tool initially missed variables mentioned in assert()s. I didn't put much time in to investigating this, but I presume it's because my compile_commands.json was build with assert()s disabled and so the names mentioned in the predicates were invisible to clang-llvm-rename. The result was that I ended up with something that built cleanly with NDEBUG, but not otherwise. I guess this is essentially the same as the #ifdef'd-out code issue you...