ExpressionVisitor and specific Javascript constructs
Sven Brauch
svenbrauch at googlemail.com
Wed Apr 9 10:40:57 UTC 2014
Hi!
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
foo.bar[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?
Greetings!
More information about the KDevelop-devel
mailing list