<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/117509/">https://git.reviewboard.kde.org/r/117509/</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 12th, 2014, 2:10 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/117509/diff/1-2/?file=264915#file264915line41" style="color: black; font-weight: bold; text-decoration: underline;">duchain/expressionvisitor.cpp</a>
<span style="font-weight: normal;">
(Diff revisions 1 - 2)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">ExpressionVisitor::ExpressionVisitor(DUContext* context) :</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2">41</font></th>
<td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="k">static</span> <span class="k">const</span> <span class="kt">double</span> <span class="n">epsilon</span> <span class="o">=</span> <span class="mf">0.0000001</span><span class="p">;</span></pre></td>
<th bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">41</font></th>
<td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="kt">int</span> <span class="n">num_int_digits</span> <span class="o">=</span> <span class="p">(</span><span class="kt">int</span><span class="p">)</span><span class="n">std</span><span class="o">::</span><span class="n">log10</span><span class="p">(</span><span class="n">node</span><span class="o">-></span><span class="n">value</span><span class="p">)</span> <span class="o">+</span> <span class="mi">1</span><span class="p">;</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;">Ah, the parser even gives you the string. Then I think searching that for a dot would be fine, and easier to read than the log10 stuff. But you can also keep it like this, I don't care.</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;">The parser only provides the position of the token. The string must be retrieved by using ParseSession::symbolAt. This solution would require that ExpressionVisitor knows about ParseSession, and I don't know if it is possible in the code-completion context.</pre>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 12th, 2014, 2:10 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/117509/diff/2/?file=264932#file264932line31" style="color: black; font-weight: bold; text-decoration: underline;">tests/files/helloworld.js</a>
<span style="font-weight: normal;">
(Diff revision 2)
</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">31</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cm"> * "EXPECT_FAIL" : { "type" : "function expressions not yet handled" },</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;">Hmm, what part of your patch breaks this (if it was working before)?</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;">I removed ExpressionVisitor::endVisit(QmlJS::AST::FunctionExpression*). This method built a simple FunctionType returning void. As ContextBuilder already recognized function expressions and built a context for them and their parameters, the tests passed but is was fragile. My following patches are (in this order, if it suits you) : adding support for "a == b", adding back support for function expressions (using anonymous declarations), adding support for unsure types (in return statements), adding support for variables whose types are known only after their declaration ("function foo(a) { a = 5; }", a is an int), inferring the type of function parameters using their call-sites ("foo(5, 3.14)" takes two parameters: int and double) and then I will start my research about objects and function prototypes :-) . All these patches should be very simple and self-contained.</pre>
<br />
<p>- Denis</p>
<br />
<p>On April 12th, 2014, 11:01 a.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 12, 2014, 11:01 a.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 is a stripped-down version of review #117458. It changes ExpressionVisitor and ContextBuilder::findType in order to use the same architecture as the one used by Ruby. As Javascript expressions can contain declarations (for instance in "var c = function() { var b = 5; return b; }"), ExpressionVisitor can have problems finding the type of such expressions. By first letting DeclarationBuilder recurse in the expression (and build every declaration it encounters), ExpressionVisitor becomes able to see them and to return their type. ExpressionVisitor is also changed to stop visiting nodes the first time it encounters a type it can deduce, as there is no need to recurse all the way to the bottom of very long JS expressions.
This patch does not add any feature to the JS language support and only changes what is required in order to have ExpressionVisitor leverage DeclarationBuilder to build declarations. This patch also moves code around and improves how double and int numbers are differentiated. I've put these cleanups in this patch because it already rewrites most of ExpressionVisitor, and the next patches are easier to understand if they don't move anything and just add methods.</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;">The QML/JS testsuite passes with this patch, with two tests marked as expected to fail. The reason is that function expressions are not yet recognized by the parser, so "var c = function(a) { return a; }" doesn't have a type yet.</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/CMakeLists.txt <span style="color: grey">(9fab69c)</span></li>
<li>duchain/contextbuilder.cpp <span style="color: grey">(d38da2d)</span></li>
<li>duchain/declarationbuilder.h <span style="color: grey">(001c3b2)</span></li>
<li>duchain/declarationbuilder.cpp <span style="color: grey">(98da341)</span></li>
<li>duchain/expressionvisitor.h <span style="color: grey">(b4f0851)</span></li>
<li>duchain/expressionvisitor.cpp <span style="color: grey">(766435d)</span></li>
<li>duchain/parsesession.h <span style="color: grey">(0eb2762)</span></li>
<li>duchain/parsesession.cpp <span style="color: grey">(dbc4d90)</span></li>
<li>duchain/tests/testdeclarations.cpp <span style="color: grey">(668efaa)</span></li>
<li>tests/files/helloworld.js <span style="color: grey">(ff40f1c)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/117509/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>