<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="https://git.reviewboard.kde.org/r/117535/">https://git.reviewboard.kde.org/r/117535/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 13th, 2014, 12:38 p.m. UTC, <b>Sven Brauch</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/117535/diff/1/?file=265119#file265119line55" style="color: black; font-weight: bold; text-decoration: underline;">duchain/helper.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">55</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="c1">// If a variable can be "mixed or something", then only keep the mixed,</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Definitely not the right thing to do. Don't discard the information you have. You can either do unsure(mixed, T) or just T, I would go for the latter, but definitely not just mixed.
mixed is the analyzer admitting complete defeat and is entirely useless. Avoid it at all costs.</pre>
</blockquote>
<p>On April 13th, 2014, 1:04 p.m. UTC, <b>Denis Steckelmacher</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;">If a function can return unsure(mixed, T), I would not say that it returns T because the user will then expect that the function will always return T, which is not the case. Maybe unsure(mixed, T) is the solution, if you don't want to lose the T. My view was that if the analyzer doesn't know the type of one return statement, then it doesn't know the return type of the function, even if other return statements have a definite type. Moreover, if the user assigns a "mixed" value to a variable, then the variable can be of any type, even if it sometimes receives a value of type T.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Let me cite an example from the python world: http://i.imgur.com/bKLZMdF.png. The analyzer doesn't know the content types of self.keys, self.values, or self.comments. Still, the return type it deduces is completely correct because the if ... else "err". Your method would return "mixed" here -- a huge loss.
What you have to keep in mind is that your analyzer doesn't know anything anyways. The user could always do funny runtime behaviour and completely screw everything up. So the best it can do is provide a reasonable guess. And if you can determine that the function returns T in one place, then it's a reasonable guess that the function returns T. Yes, this might not be the full truth, but the user will have to cope with that.</pre>
<br />
<p>- Sven</p>
<br />
<p>On April 13th, 2014, 12:17 p.m. UTC, Denis Steckelmacher wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDevelop.</div>
<div>By Denis Steckelmacher.</div>
<p style="color: grey;"><i>Updated April 13, 2014, 12:17 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdev-qmljs
</div>
<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;">This patch introduces the mergeTypes() function, based on the same function in kdev-python. Its behavior differs from the Python one in several aspects, though:
* Mixed types absorb other types (the function never returns "unsure(mixed, int)", but simply "mixed"). I'm not sure that it is the right thing to do, but I think that the "mixed" type is generally used to represent an unknown type. The user therefore gains no information by knowing that a function returns "anything, and this anything can sometimes be an int".
* The function makes more assumptions than the Python one. For instance, I know that the second type passed to it is never NULL, and that the function will be used to add a return type to a function or to add a type of a variable.
This function is used to merge the type of all the return statements of a function. This way, the user can know when a function may return values of different types. A future patch will also use this function to deduce the type of variables using assignments to them. </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;">4 tests have been added. They test the basic features of mergeTypes and some corner cases (how voids should be handled, different return statements having the same type and how mixed should take precedence over other types).</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>duchain/declarationbuilder.cpp <span style="color: grey">(fe131ce)</span></li>
<li>duchain/helper.h <span style="color: grey">(23a6d0e)</span></li>
<li>duchain/helper.cpp <span style="color: grey">(3ffdd56)</span></li>
<li>tests/files/helloworld.js <span style="color: grey">(1ce3815)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/117535/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>