<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/103071/">http://git.reviewboard.kde.org/r/103071/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On November 8th, 2011, 2:01 p.m., <b>David Nolden</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I am not convinced that this should be added to kdevplatform. The problem is that the duchain API is too complex already and hard to maintain, it needs some cleaning up rather than adding new stuff.
The use-cases of the added classes seem very specific, and it's very unprobable that other languages will implement this level of information-detail, so why cannot this stuff be stored separately together with the C++ specific checker code?
In general, we have to see how much of your thesis we can integrate into kdevelop. For example, the "imports" check could be integrated either as a simple "Problem", or as a "Cleanup Imports" action in the "Code" menu. IMO the most useful and simple checks should be integrated seamlessly in such ways, rather than adding a separate "checker" UI. We have to keep the maintainability of the whole code in mind though, so the complexity of added code has always to be weighted against its usefulnes.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I think it doesn't hurt to have these classes, they have extremely simple implementations and have proved quite powerful when analyzing problems on the code. The actual complexity resides inside the C++ code and anyway its complexity is nowhere comparable to the DUChain's.
Regarding GUI, I don't plan to integrate it for the moment, all these checks are generating IProblem tuples so there's no problem to make it look seamless to the user experience. There are other parts created that should be merged to have it all working together but I've thought all this project so that it creates much maintainability problems, I think we shouldn't just deny it because it's different from what we have.</pre>
<br />
<p>- Aleix</p>
<br />
<p>On November 8th, 2011, 2:03 a.m., Aleix Pol Gonzalez wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDevelop, Milian Wolff and David Nolden.</div>
<div>By Aleix Pol Gonzalez.</div>
<p style="color: grey;"><i>Updated Nov. 8, 2011, 2:03 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As some of you will know, my master thesis was built on top of kdevelop with the idea to add some static analysis capabilities to KDevelop/KDevPlatform by adding some new tools and stuff. A document describing what I did can be found here: http://proli.net/meu/pfc/memoria.pdf
In this patch there's the changes I made in the KDevPlatform, mostly to add the DataAccessRepository and the ControlFlowGraph (Chapter 2) data types and the ILanguageCheck and ILanguageCheck provider (Chapter 3).
If there's any question just ask me :). I'll submit another patch for KDevelop, implementing these features shortly.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Well, the testing is what I've built on top. It's coming, I'm just fixing some issues after merging from master. It wasn't as bad as I expected though ;).</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>language/CMakeLists.txt <span style="color: grey">(eb85b2c)</span></li>
<li>language/backgroundparser/parsejob.h <span style="color: grey">(135319c)</span></li>
<li>language/checks/controlflowgraph.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/controlflowgraph.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/controlflownode.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/controlflownode.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/dataaccess.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/dataaccess.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/dataaccessrepository.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>language/checks/dataaccessrepository.cpp <span style="color: grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/103071/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>