[cfe-dev] [ycm-dev] libclang: diagnostics not reported for template instantiations

[Manuel Klimek via cfe-dev]

I believe once people have modules builds we'll be able to revisit the flag.

On Sun, Nov 1, 2015 at 9:36 AM Ben Jackson <puremourning at gmail.com> wrote:

> Yep. Confirmed removing that flag gets a diagnostic in the test case.
> Thanks for the input.
>
>
> On 1 Nov 2015, at 17:26, Val Markovic <val at markovic.io> wrote:
>
> 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 *may* 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.
>
> On Sun, Nov 1, 2015 at 9:22 AM, Ben Jackson <puremourning at gmail.com>
> wrote:
>
>> Val,
>>
>> I think you might be right. I will try it out to confirm, but the docs
>> look to point to exactly that:
>>
>> *CXTranslationUnit_Incomplete*
>>
>> Used to indicate that the translation unit is incomplete.
>>
>> 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, this suppresses the completion of tentative
>> declarations in C and of instantiation of implicitly-instantiation function
>> templates in C++. This option is typically used when parsing a header
>> with the intent of producing a precompiled header.
>>
>> Thanks,
>> Ben
>>
>>
>> On 1 Nov 2015, at 17:12, Val Markovic <val at markovic.io> wrote:
>>
>> Could this be related to the Incomplete flag we started passing to
>> libclang a while ago?
>>
>> On Sun, Nov 1, 2015 at 9:11 AM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> +Benjamin
>>>
>>> On Tue, Oct 27, 2015 at 5:15 PM Val Markovic <val at markovic.io> wrote:
>>>
>>>> +klimek
>>>>
>>>> On Mon, Oct 26, 2015 at 3:09 PM, Ben Jackson <puremourning at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> 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).
>>>>>
>>>>> A fairly canonical test case is as follows:
>>>>>
>>>>>     template<typename T>
>>>>>     void get_size(const T& t)
>>>>>     {
>>>>>         return t.size();
>>>>>     }
>>>>>
>>>>>     struct Test
>>>>>     {
>>>>>         void not_size() const;
>>>>>     };
>>>>>
>>>>>     int run_test()
>>>>>     {
>>>>>         Test t;
>>>>>
>>>>>         get_size(t);
>>>>>
>>>>>         return "not_an_int";
>>>>>     }
>>>>>
>>>>> 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.
>>>>>
>>>>> The ‘return “not_an_int”’ is just to prove that diagnostics reporting
>>>>> is working in general in the test case.
>>>>>
>>>>> When running the above with ‘c-index-test -index-file’, grepping for
>>>>> ‘[diagnostic]’, the result is :
>>>>>
>>>>>     $ ./bin/c-index-test -index-file
>>>>> ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp  |
>>>>> grep '\[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]'
>>>>> [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]'
>>>>>
>>>>> However, when running clang directly, we get the diagnostic for
>>>>> get_size(t):
>>>>>
>>>>>      clang++
>>>>> ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp
>>>>>
>>>>> ../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]'
>>>>>         return "not_an_int";
>>>>>            ^~~~~~~~~~~~
>>>>>
>>>>> ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:4:14:
>>>>> error: no member named 'size' in 'Test'
>>>>>         return t.size();
>>>>>            ~ ^
>>>>>
>>>>> ../llvm/tools/clang/test/Index/diagnostics-template-instantiation.cpp:16:5:
>>>>> note: in instantiation of function template specialization 'get_size<Test>'
>>>>> requested here
>>>>>         get_size(t);
>>>>>     ^
>>>>>     2 errors generated.
>>>>>
>>>>> 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.
>>>>>
>>>>
>>> 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.
>>>
>>>
>>>>
>>>>> Many thanks and kind regards,
>>>>> Ben
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ycm-dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to ycm-dev+unsubscribe at googlegroups.com.
>>>>> To post to this group, send email to ycm-dev at googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/ycm-dev/41DF481E-282F-4C3D-A4F8-19CC9C706AE0%40gmail.com
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151101/9a0fcfff/attachment.html>