[GSoC 2014] Integrating Clang in KDevelop

[Kevin Funk]

Am Donnerstag, 6. März 2014, 18:45:08 schrieb 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.

Hey Denis!

We have that already (although no icon), the katepart can be configured to 
mark faulty lines in red (afaik it's not enabled by default). We also show a 
summary of the error in a tooltip, and that could also be shown in a separate 
windows easily.

Anything else you miss?

> 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.

Yep, I think it totally makes sense to re-use this infrastructure for 
additional analyzers. You could easily show them in the problem toolview (or a 
clone of it) as well.

> 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?

By the way, to the list: I'm also pondering if I'm going to do a GSoC this 
year. Preferably I'd like to streamline our Clang support plugin so it gets 
fully production ready. This is the last chance I have, given that I'm about 
to finish my master's degree this summer ;)

Just an idea, though, I'm not sure if time permits it.

Cheers

-- 
Kevin Funk