<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov <<a href="mailto:sepavloff@gmail.com">sepavloff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is created in the directory <build-dir>/tools/clang/tools/extra/test/clang-tidy/Output, </div></blockquote><div><br>I'd be really surprised if this is the case - why would cmake/ninja/makefiles put the compile commands for the whole LLVM project/build in that somewhat random subdirectory?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">but the tests from <src-dir>/llvm/tools/clang/tools/extra/test/clang-tidy run in the directory <build-dir>/tools/clang/tools/extra/test/clang-tidy, which does not contain json files. So the test passes successfully. Ubuntu 16.04, cmake 3.5.1.</div></blockquote><div><br>Ah, perhaps you found a compile_commands for one of the test cases, not the one generated by CMake. CMake 3.5.1 doesn't support CMAKE_EXPORT_COMPILE_COMMANDS.<br><br>It was added in 3.5.2, according to the documentation: <a href="https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html">https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html</a><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br clear="all"><div><div class="m_-8003693347244015779gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">2017-06-24 9:42 GMT+07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ping (+Manuel, perhaps he's got some ideas about this, given background in the tooling & compilation database work, or could point this to someone who does?)<div><div class="m_-8003693347244015779h5"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 15, 2017 at 10:40 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="https://sarcasm.github.io/notes/dev/compilation-database.html#cmake" target="_blank">https://sarcasm.github.io/notes/dev/compilation-database.html#cmake</a><br><br>If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have a sufficiently recent cmake), then CMake will generate a compile_commands.json in the root of the build tree. The test finds this & fails, instead of finding no compilation database & succeeding.<br><br>(to use this, you can then symlink from the root of the source tree to point to this in your build tree - this is how I get YCM to work for my LLVM builds & could work for other clang tools as well)</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-15 2:43 GMT+07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-14 4:24 GMT+07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ah, I find that the test passes if I remove the compile_commands.json file from my build directory (I have Ninja configured to generate a compile_commands.json file).<br><br>Looks like what happens is it finds the compilation database and fails hard when the database doesn't contain a compile command for the file in question. If the database is not found, it falls back to some basic command behavior, perhaps?<br><br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>You are right, constructor of `CommonOptionsParser` calls `autoDetectFromSource` or `autoDetectFromDirectory` prior to final construction of `FixedCompilationDatabase.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is there some way this test could be fixed to cope with this, otherwise it seems to get in the way of people actually using clang tools in their LLVM/Clang build environment?</div><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-HOEnZb"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-h5"><br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>IIUC, presence of stale compilation database file in test directory could break many tests. I don't understand why only diagnostic.cpp fails, probably there is something wrong with the clang-tidy application cleanup in this case?</div></div></div></div></blockquote></div><div><br></div></span><div>Except it's neither stale nor in the test directory.</div><div><br></div><div>It's the up to date/useful/used compile_commands.json generated by ninja in the root of the build tree.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I miss something. If I could reproduce the problem, I would investigate it.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154HOEnZb"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154h5"><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-HOEnZb"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-h5"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I cannot reproduce such fail, so I can only guess how changes made in <a href="https://reviews.llvm.org/rL303756" target="_blank">https://reviews.llvm.org/rL303756</a> and <a href="https://reviews.llvm.org/rL303741" target="_blank">https://reviews.llvm.org/rL303741</a> could cause such problem. Behavior of `Driver::BuildCompilation` is changed so that it returns null pointer if errors occur during driver argument parse. It is called in `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at this point is:</div><div><span class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>stripPositionalArgs</div><div><span class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>clang::tooling::FixedCompilationDatabase::loadFromCommandLine</div><div><span class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>clang::tooling::CommonOptionsParser::CommonOptionsParser</div><div><span class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>clang::tidy::clangTidyMain</div><div><span class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>main</div><div>`FixedCompilationDatabase::loadFromCommandLine` returns null and CommonOptionsParser uses another method to create compilation database. The output "Compile command not found" means that no input file were found in `ClangTool::run`. Maybe some file names are nulls?</div><div><br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554gmail_signature">Thanks,<br>--Serge<br></div></div></div></div><div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">2017-06-13 3:42 GMT+07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I've been seeing errors from this test recently:<br><br><div>Command Output (stderr):</div><div>--</div><div>1 error generated.</div><div>Error while processing /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.</div><div>/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12: error: expected string not found in input</div><span><div>// CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]</div></span><div> ^</div><div><stdin>:2:1: note: scanning from here</div><div>Skipping /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp. Compile command not found.</div><div>^</div><div><stdin>:2:1: note: with expression "@LINE+2" equal to "12"</div><div>Skipping /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp. Compile command not found.</div><div>^<br><br><br>Specifically, the output is:<br>$ ./bin/clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor' /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp -- -fan-unknown-option 2>&1 error: unknown argument: '-fan-unknown-option' Skipping /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp. Compile command not found.<br><br><br>Does this look like it might be related to any of your changes in this area? Perhaps the error due to unknown argument is causing clang-tidy not to continue on to run the check & report the warning?<br><br></div></div><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554HOEnZb"><div class="m_-8003693347244015779m_8696128945258540158m_6306377020224299443m_128872016728090154m_7225409136167520337m_-6784515729235465945gmail-m_8674514643682799494gmail-m_8339286651193700295m_260147376041695554h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, May 24, 2017 at 3:51 AM Serge Pavlov via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Author: sepavloff<br>
Date: Wed May 24 05:50:56 2017<br>
New Revision: 303735<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=303735&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=303735&view=rev</a><br>
Log:<br>
Modify test so that it looks for patterns in stderr as well<br>
<br>
With the change <a href="https://reviews.llvm.org/D33013" rel="noreferrer" target="_blank">https://reviews.llvm.org/D33013</a> driver will not build<br>
compilation object if command line is invalid, in particular, if<br>
unrecognized option is provided. In such cases it will prints diagnostics<br>
on stderr. The test 'clang-tidy/diagnostic.cpp' checks reaction on<br>
unrecognized option and will fail when D33013 is applied because it checks<br>
only stdout for test patterns and expects the name of diagnostic category<br>
prepared by clang-tidy. With this change the test makes more general check<br>
and must work in either case.<br>
<br>
Differential Revision: <a href="https://reviews.llvm.org/D33173" rel="noreferrer" target="_blank">https://reviews.llvm.org/D33173</a><br>
<br>
Modified:<br>
clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp<br>
<br>
Modified: clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp?rev=303735&r1=303734&r2=303735&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp?rev=303735&r1=303734&r2=303735&view=diff</a><br>
==============================================================================<br>
--- clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp (original)<br>
+++ clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp Wed May 24 05:50:56 2017<br>
@@ -1,11 +1,11 @@<br>
// RUN: clang-tidy -checks='-*,modernize-use-override' %s.nonexistent.cpp -- | FileCheck -check-prefix=CHECK1 -implicit-check-not='{{warning:|error:}}' %s<br>
-// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s -- -fan-unknown-option | FileCheck -check-prefix=CHECK2 -implicit-check-not='{{warning:|error:}}' %s<br>
-// RUN: clang-tidy -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s -- -fan-unknown-option | FileCheck -check-prefix=CHECK3 -implicit-check-not='{{warning:|error:}}' %s<br>
+// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK2 -implicit-check-not='{{warning:|error:}}' %s<br>
+// RUN: clang-tidy -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK3 -implicit-check-not='{{warning:|error:}}' %s<br>
// RUN: clang-tidy -checks='-*,modernize-use-override,clang-diagnostic-macro-redefined' %s -- -DMACRO_FROM_COMMAND_LINE | FileCheck -check-prefix=CHECK4 -implicit-check-not='{{warning:|error:}}' %s<br>
<br>
// CHECK1: error: error reading '{{.*}}.nonexistent.cpp' [clang-diagnostic-error]<br>
-// CHECK2: error: unknown argument: '-fan-unknown-option' [clang-diagnostic-error]<br>
-// CHECK3: error: unknown argument: '-fan-unknown-option' [clang-diagnostic-error]<br>
+// CHECK2: error: unknown argument: '-fan-unknown-option'<br>
+// CHECK3: error: unknown argument: '-fan-unknown-option'<br>
<br>
// CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]<br>
// CHECK3: :[[@LINE+1]]:9: warning: implicit conversion from 'double' to 'int' changes value<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div></div></blockquote></div>
</div></div></blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div></div></div></blockquote></div></blockquote></div></div></div></div>
</blockquote></div><br></div></blockquote></div></div>