ExpressionVisitor and specific Javascript constructs

Sven Brauch svenbrauch at
Wed Apr 9 10:40:57 UTC 2014


On Wednesday 09 April 2014 11:44:33 Denis Steckelmacher wrote:
> var a = function() {
>      var b = 5;
>      return b;
> }
> This snippet exposes three areas where ExpressionVisitor has
> difficulties to find the type of expressions:
Indeed, you're right. I didn't think about that. That will be ugly to handle 
if you want to visit the function as an expression, as you already said.

Thinking about it, Python has the same problem and solves it by simply not 
supporting it. That's not a problem there though, since this syntax can only 
be used for functions which only have one statement in their body, and it's 
discouraged to assign those to a name so effectively nobody is doing it. In JS 
this is obviously different. :(

Your previous solution seems better suited for this particular case, but you 
lose the flexibility to determine the type of an expression outside of the 
builders (e.g. for completion) entirely ... so I am unsure how you would do 
that in the completion context then (assume you want to do completion on[3].x.<cursor>, if you can't just throw that expression into something 
you are using in the analyzer anyways, it will either need a lot of duplicated 
functionality or will just not work).

I see two other solutions:
 1) simply make the declarationbuilder recognize this particular construct and 
treat it like function a() { ... }. That's a rather simple solution but it's 
not very future-proof, unfortunately, since there are other similar cases with 
the same problem most likely. Still, maybe this is what we should do for now 
-- it's simple and probably catches almost all cases.
 2) this one I'm not sure about if it would work and it also sounds quite 
adventurous: You could in general build function contexts in the expression 
visitor. The openContext() method is not needed to instantiate contexts; you 
can create a DUContext* yourself, and then return it and open it from the 
context builder to merge it with the surrounding code. As said, I don't know 
if this would work and whether it would be ugly or not. It's probably not a 
good idea.

Aleix, do you have any bright ideas regarding this?


More information about the KDevelop-devel mailing list