Review Request: Make AbstractFunctionDeclaration store a reference to its FunctionContext

[Olivier Jean de Gaalon]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106764/
-----------------------------------------------------------

(Updated Oct. 8, 2012, 12:27 p.m.)


Review request for KDevelop, Milian Wolff and David Nolden.


Description
-------

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.


Diffs
-----

  language/duchain/abstractfunctiondeclaration.h 7c033fc 
  language/duchain/abstractfunctiondeclaration.cpp 68e9964 
  language/duchain/ducontext.cpp de08fea 

Diff: http://git.reviewboard.kde.org/r/106764/diff/


Testing
-------

Tests run, no crashes in usage.


Thanks,

Olivier Jean de Gaalon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121008/05edd458/attachment.html>