<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 29, 2018 at 11:34 AM Christian Dullweber <<a href="mailto:dullweber@chromium.org">dullweber@chromium.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"><div dir="ltr">Sound great, thanks! <div><br></div><div>One interesting case in Chromium might be generated jni headers. I would be interested what the heuristic finds for these files:<div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">src/out/Android/gen/chrome/browser/jni_headers/chrome/jni/BrowsingDataBridge_jni.h</span></div></div></div></div></blockquote><div>Indeed, it doesn't do well here, but still compiles fine - this seems to be the case when the exact flags used don't matter much as long as the general project setup is right. Probably quite common in generated files - I guess these tend to have relatively few predictable dependencies, and might prefer unwieldy fully-qualified include paths where a human would add a -I entry. This one includes <jni.h> and "../../../../../../../../base/android/jni_generator/jni_generator_helper.h".</div><div><br></div><div>The heuristic fares poorly here because the filename is unique, the last few path components (chrome, jni, jni_headers) are unhelpful in locating related cc files, and the "nearby in the tree" logic doesn't handle the separate root for genfiles well.</div><div>The right file turns out to be e.g. "chrome/browser/android/browsing_data/browsing_data_bridge.cc". The only useful hints here are chrome/browser (not very specific) and BrowsingDataBridge if we used fuzzy word matching to account for case differences. I'm inclined not to try to solve this case without more data.<br></div><div><br></div><div>The only diagnostics produced are a bunch of "internal linkage... but not defined" where the header forward declares static functions whose implementations are meant to be provided by the including CC file.</div><div>This is an artifact of assuming the .h file is standalone, and it seems like a form of non-modularity, but this is a minor issue we can deal with in a few ways and unrelated to the choice of flags.</div><div><br></div><div>Relevant logs are:</div><div><div>Chose /usr/local/google/home/sammccall/src/chromium/src/out/Android/gen/chrome/browser/android/proto/<a href="http://client_discourse_context.pb.cc">client_discourse_context.pb.cc</a> as proxy for /usr/local/google/home/sammccall/src/chromium/src/out/Android/gen/chrome/browser/jni_headers/chrome/jni/BrowsingDataBridge_jni.h</div></div><div><br></div><div><div>Rebuilding file /usr/local/google/home/sammccall/src/chromium/src/out/Android/gen/chrome/browser/jni_headers/chrome/jni/BrowsingDataBridge_jni.h with command [/usr/local/google/home/sammccall/src/chromium/src/out/Android] ../../third_party/llvm-build/Release+Asserts/bin/clang++ -x c++ -MMD -MF obj/chrome/browser/client_discourse_context_proto/client_discourse_context.pb.o.d -D V8_DEPRECATION_WARNINGS -D NO_TCMALLOC -D SAFE_BROWSING_DB_REMOTE -D CHROMIUM_BUILD -D FIELDTRIAL_TESTING_ENABLED -D ANDROID -D HAVE_SYS_UIO_H -D ANDROID_NDK_VERSION_ROLL=r16_1 -D CR_CLANG_REVISION="328575-1" -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D COMPONENT_BUILD -D __GNU_SOURCE=1 -D CHROMIUM_CXX_TWEAK_INLINES -D _DEBUG -D DYNAMIC_ANNOTATIONS_ENABLED=1 -D WTF_USE_DYNAMIC_ANNOTATIONS=1 -D GOOGLE_PROTOBUF_NO_RTTI -D GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -D HAVE_PTHREAD -D PROTOBUF_USE_DLLS -I ../.. -I gen -I ../../third_party/protobuf/src -I gen/protoc_out -I ../../third_party/protobuf/src -fno-strict-aliasing --param ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D __DATE__= -D __TIME__= -D __TIMESTAMP__= -funwind-tables -fPIC -pipe -fcolor-diagnostics -no-canonical-prefixes -ffunction-sections -fno-short-enums --target=arm-linux-androideabi -isystem ../../third_party/android_ndk/sysroot/usr/include/arm-linux-androideabi -D __ANDROID_API__=16 -D __NDK_FPABI__= -D HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC=1 -march=armv7-a -mfloat-abi=softfp -mtune=generic-armv7-a -mfpu=neon -mthumb -Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-unused-lambda-capture -Wno-user-defined-warnings -Wno-enum-compare-switch -Wno-null-pointer-arithmetic -Wno-ignored-pragma-optimize -Oz -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -gdwarf-3 -g2 -ggnu-pubnames -fvisibility=hidden -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=gnu++14 -fno-exceptions -fno-rtti -isystem ../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include -isystem ../../third_party/android_ndk/sources/cxx-stl/llvm-libc++abi/include -isystem ../../third_party/android_ndk/sources/android/support/include --sysroot=../../third_party/android_ndk/sysroot -fvisibility-inlines-hidden -c /usr/local/google/home/sammccall/src/chromium/src/out/Android/gen/chrome/browser/jni_headers/chrome/jni/BrowsingDataBridge_jni.h -resource-dir=/usr/local/google/home/sammccall/llvmbuild/bin/../lib/clang/7.0.0</div></div><div><br></div><div>(Yes, the -M flags should really be filtered)</div><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 dir="ltr"><div><div><div><br></div><div>the implementation is in:<br></div><div><div>src/chrome/browser/android/browsing_data/browsing_data_bridge.cc<br></div></div><div>I don't think that will get matched.</div><div><br></div><div></div></div></div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I don't really care if code completion works in generated files but at least there shouldn't be incorrect error messages in vscode. Is it possible to exclude a folder from being analyzed by clangd?</span></div></blockquote><div>Not currently, it'll look at anything with a supported extension.</div><div>It's not obvious to me how to manage either heuristically or via configuration in a way that's easy to use, so unless people have ideas I'd punt on this and try to improve the results instead.</div><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 dir="ltr"><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 29, 2018 at 1:50 AM, Sam McCall <span dir="ltr"><<a href="mailto:sammccall@google.com" target="_blank">sammccall@google.com</a>></span> wrote:<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">Looks like our mail crossed :)<div>Cquery's success with this is another point in favor.</div><div><br></div><div>I have a prototype in <a href="https://reviews.llvm.org/D45006" target="_blank">https://reviews.llvm.org/D45006</a> (+ 2-line patch to enable in clangd: <a href="https://reviews.llvm.org/D45007" target="_blank">https://reviews.llvm.org/D45007</a>).</div><div>It seems to work pretty well at first glance, but it needs rigorous testing. If anyone's feeling this pain, feel free to try it out!</div><div><br></div><div>It does a little bit of indexing to avoid traversing all the entries every time, not sure if that's worth it.</div></div><div class="gmail-m_5238143788924828592HOEnZb"><div class="gmail-m_5238143788924828592h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 28, 2018 at 9:58 PM Fāng-ruì Sòng via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@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"><div dir="ltr">Another heuristic solution:<div><br></div><div>Enumerate all compilation database entries and calculate the matching score for each entry with the target file<br>Bonus for common leading components<br>Penalty for diverged path components<br>Bonus for common trailing characters sans filename extension (e.g. Match.cc Match.h are the same sans extension)<br><br>This heuristic is used in cquery.<br><br>Add another point for textDocument/didOpen on an unseen filename:<br>The inferred command line options are not authoritative, they should be overriden by other translation units when later it turns out the header file is included by some entry in the compilation database.</div></div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 28, 2018 at 7:12 AM Christian Dullweber via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@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"><div dir="ltr">Hi,<div><br></div><div>I recently tried to use clangd for Chromium in vscode and hit the same issue. </div><div>I experimented a bit with generating a compile_commands.json file with valid rules for headers and came to this solution: <a href="https://gist.github.com/xchrdw/bfd2b3a5f765f4195a55d6351daf1b48" target="_blank">https://gist.github.com/xchrdw/bfd2b3a5f765f4195a55d6351daf1b48</a></div><div>I sorted all .cc filenames and then looked up the index of the closest match<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>for each header </span>using binary search. As there were some edge cases like the first or last file in a directory, I additionally compared which file at the index has the largest prefix with the header.</div><div>I found a few issues with system headers and some generated protobuf headers but otherwise it works well.</div><div>Native support from clangd would be amazing :)</div><div><br></div><div>Thanks,</div><div>Christian</div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_5238143788924828592m_-2071493688234920741m_-5510749033118636740gmail_signature"><div dir="ltr">宋方睿</div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div>