<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/106764/">http://git.reviewboard.kde.org/r/106764/</a>
</td>
</tr>
</table>
<br />
<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 Olivier Jean de Gaalon.</div>
<p style="color: grey;"><i>Updated Oct. 8, 2012, 12:27 p.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;">This is needed for function specialization.
The problem background:
A function's internalContext will point to either the function's argument context, or, if one exists (ie, in a definition), its expression context. In the latter case, the expression context will import the argument context, and that's the only way to access it.
An import (DUContext::Import) effectively has two types, say specialization types and normal types. The normal type just stores a reference the actual DUContext being imported. The specialization type instead stores a declarationId, which is resolved to return the declaration's internalContext() as the import.
The problem:
A function specialization's expression context thinks it's importing the parameter context, in reality the context is importing a declaration id which points right back to the expression context via internalContext. Therefore a specialization function's expression context will import itself and be blissfully unaware of its own parameters (and crash).
The solution:
1. If an AbstractFunctionDeclaration knows where its parameter context is, it doesn't have to ask its expression context for it, so reference it.
2. As far as I know, a function's expression context will never be imported into another context, therefore it's safe to say that if the declarationId of an import points to an AbstractFunctionDeclaration, the desired context is the parameter context, therefore always return the internalFunctionContext and not the internalContext in that case.
If #2 above is wrong, then DUContext::Import would have to have some bool to specify whether it wants the declarationId's internalContext or internalFunctionContext. This could be expensive. Tests pass and everything works, so it seems correct.</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;">Tests run, no crashes in usage.</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/duchain/abstractfunctiondeclaration.h <span style="color: grey">(7c033fc)</span></li>
<li>language/duchain/abstractfunctiondeclaration.cpp <span style="color: grey">(68e9964)</span></li>
<li>language/duchain/ducontext.cpp <span style="color: grey">(de08fea)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/106764/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>