<div dir="ltr">Yeah, that's almost certainly it then. The thing is, that flag gives something like a 10x perf boost when compiling large TUs. I think we almost certainly want to have it on by default, though we <i>may</i> want to expose a user-level setting to turn it off. That's a big "may" since we've been using the flag for something like a year if not more and nobody has complained about this until now.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 1, 2015 at 9:22 AM, Ben Jackson <span dir="ltr"><<a href="mailto:puremourning@gmail.com" target="_blank">puremourning@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Val, </div><div><br></div><div>I think you might be right. I will try it out to confirm, but the docs look to point to exactly that:</div><div><br></div><div><table border="0" cellspacing="2" cellpadding="0" style="font-family:'Lucida Grande',Verdana,Geneva,Arial,sans-serif;font-size:13px;line-height:1.3;color:rgb(0,0,0)"><tbody><tr><td valign="top"><em>CXTranslationUnit_Incomplete</em> </td><td><p style="line-height:1.3">Used to indicate that the translation unit is incomplete. </p><p style="line-height:1.3">When a translation unit is considered "incomplete", semantic analysis that is typically performed at the end of the translation unit will be suppressed. For example, <font color="#ff2600">this suppresses the completion of tentative declarations in C and of instantiation of implicitly-instantiation function templates in C++. </font>This option is typically used when parsing a header with the intent of producing a precompiled header.</p></td></tr></tbody></table><div><br></div></div><div>Thanks,</div><div>Ben</div><div><div class="h5"><div><br></div><br><div><blockquote type="cite"><div>On 1 Nov 2015, at 17:12, Val Markovic <<a href="mailto:val@markovic.io" target="_blank">val@markovic.io</a>> wrote:</div><br><div><div dir="ltr">Could this be related to the Incomplete flag we started passing to libclang a while ago?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 1, 2015 at 9:11 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+Benjamin <div><br><div class="gmail_quote"><div><div><div dir="ltr">On Tue, Oct 27, 2015 at 5:15 PM Val Markovic <<a href="mailto:val@markovic.io" target="_blank">val@markovic.io</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">+klimek</div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 3:09 PM, Ben Jackson <span dir="ltr"><<a href="mailto:puremourning@gmail.com" target="_blank">puremourning@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
An issue was raised against ycmd that we were not reporting errors as a result of failed template instantiations. This is because, seemingly, libclang does not report diagnostics for template instantiations where instantiation fails (in the sense that the generated code is not valid).<br>
<br>
A fairly canonical test case is as follows:<br>
<br>
    template<typename T><br>
    void get_size(const T& t)<br>
    {<br>
        return t.size();<br>
    }<br>
<br>
    struct Test<br>
    {<br>
        void not_size() const;<br>
    };<br>
<br>
    int run_test()<br>
    {<br>
        Test t;<br>
<br>
        get_size(t);<br>
<br>
        return "not_an_int";<br>
    }<br>
<br>
Expected: a diagnostic reported at the line ‘get_size(t)’ as struct Test does not have a size()const method. However, no diagnostic is reported.<br>
<br>
The ‘return “not_an_int”’ is just to prove that diagnostics reporting is working in general in the test case.<br>
<br>
When running the above with ‘c-index-test -index-file’, grepping for ‘[diagnostic]’, the result is :<br>
<br>
    $ ./bin/c-index-test -index-file ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp  | grep '\[diagnostic\]'<br>
    ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:18:12: error: cannot initialize return object of type 'int' with an lvalue of type 'const char [11]'<br>
[diagnostic]: ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:18:12: error: cannot initialize return object of type ‘int' with an lvalue of type 'const char [11]'<br>
<br>
However, when running clang directly, we get the diagnostic for get_size(t):<br>
<br>
     clang++ ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp<br>
    ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:18:12: error: cannot initialize return object of type 'int' with an lvalue of type 'const char [11]'<br>
        return "not_an_int";<br>
           ^~~~~~~~~~~~<br>
    ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:4:14: error: no member named 'size' in 'Test'<br>
        return t.size();<br>
           ~ ^<br>
    ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:16:5: note: in instantiation of function template specialization 'get_size<Test>' requested here<br>
        get_size(t);<br>
    ^<br>
    2 errors generated.<br>
<br>
Is this a bug or simply a limitation of the libclang interface? Or is there something required to get these diagnostics to report. Apologies, I must confess I have not looked into this in detail within clang.<br></blockquote></div></div></div></blockquote><div><br></div></div></div><div>I'd expect there to be a way to drive libclang to get those diagnostics. On the other hand, it would probably mean a significant slow-down, because template instantiation can be a significant amount of the parse time.</div><span><div> </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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Many thanks and kind regards,<br>
Ben<br>
<span><font color="#888888"><br>
--<br>
You received this message because you are subscribed to the Google Groups "ycm-dev" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:ycm-dev%2Bunsubscribe@googlegroups.com" target="_blank">ycm-dev+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href="mailto:ycm-dev@googlegroups.com" target="_blank">ycm-dev@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/ycm-dev/41DF481E-282F-4C3D-A4F8-19CC9C706AE0%40gmail.com" rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/ycm-dev/41DF481E-282F-4C3D-A4F8-19CC9C706AE0%40gmail.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
</font></span></blockquote></div><br></div></div></blockquote></span></div></div></div>
</blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>