[GSoC 2014] Integrating Clang in KDevelop

[Denis Steckelmacher]

On 03/06/2014 11:15 AM, Milian Wolff wrote:
> On Thursday 06 March 2014 10:50:33 Denis Steckelmacher wrote:
>> Hello,
>>
>> I tried to post this e-mail on the KDevelop mailing-list
>> (kdevelop-devel at kde.org), but it seems to have been blocked even if I am
>> subscribed to the mailing-list. As you seem to be the primary developer
>> of the kdev-clang plugin, I send you this e-mail so that you can forward
>> it to the right people.
>
> Hey Denis,
>
> I don't see any of your mails on the mailing list, please try again. And
> double-check whether the address is correct (see TO address of this email,
> please direct your replies there).
>
>> I have seen on the KDE's GSoC Idea Page that an idea for the Google
>> Summer of Code is to polish the Clang plugin of KDevelop, first publicly
>> presented several weeks ago, at the end of the Kate/KDevelop Sprint 2014.
>>
>> It's a project that interests me greatly, because I use Clang a my
>> primary compiler, KDevelop as my IDE of predilection, and I always
>> wanted to see the two integrated. As my GSoC 2011 was about using Clang
>> to compile OpenCL C code and to execute it, I had the occasion to dig
>> into the internals of Clang and LLVM.
>>
>> The Idea page lists several features that can still be added to the
>> Clang plugin, and a project involving the development of a checker
>> framework. The most interesting fact about Clang is that it is a
>> compiler. By using Clang, KDevelop could highlight every compile error,
>> in the spirit of what Java IDEs do ("if the IDE says it is okay, then it
>> will compile"). Would it be possible to implement that during the
>> summer? Does this behavior needs that the new checker framework is first
>> implemented?
>>
>> My preference goes for the Clang integration project, but if you think
>> that the checker framework will be more useful, it is also a project for
>> which I would be glad to apply.
>
> Sounds cool but please note that we prefer to give students a chance at the
> GSOC which previously supplied patches already. So get your hands dirty _now_.
> Also, note that there are probably multiple people interested in this project.
>
> Furthermore, from the above it sounds as if you have not yet played with the
> Clang plugin, as some of the stuff you mention is already implemented there,
> most notably the integration of the compile errors.
>
> The checker framework is something different, it would be a framework to
> integrate tools such as linters, valgrind, clang's analyzers etc. pp.
>
I hadn't already recompiled KDevelop and kdev-clang when I sent this 
e-mail, but I have do so now. I'm quite impressed with the "hint" 
feature of Clang that is exposed in KDevelop, it is very handy.

What I was talking about in the paragraph concerning errors is that 
Netbeans, that I use for the university, not only highlights compiler 
errors in the source code, but also puts an icon on the faulty line 
number, and a summary of the error in a separate window.

It's very close to what KDevelop currently does for compile errors 
(using tooltips and the Problems toolview), and also close to how it 
could be possible to integrate Valgrind, gcov and other linters: the 
output of all these tools can most of the time be mapped to a line of 
code (or a range of lines of code), with an explanatory message in a 
separate window. This is why I asked if it would be possible to use the 
same infrastructure to report problems originating from the language 
support or any kind of analyzer/lint tool.

By the way, when I tested the kdev-clang, the file 
kdev-clang/duchain/parsesession.cpp was not properly parsed by Clang 
because initializer lists were used near the beginning of the file. The 
syntax highlighting stops just after these lines and the code after them 
uses the plain Kate syntax highlighting. I would be happy to debug this 
problem, but is it a configuration problem or something already known 
(and not too complex to fix) ? Are bugs related to kdev-clang already on 
bugs.kde.org?