<div dir="ltr">Hi there,<div><br></div><div>The Ruby guy here stepping in :) In Ruby you can do exactly the same thing:</div><div><br></div><div>a = def foo</div><div>  b = 'string'</div><div>  b</div><div>end</div>
<div><br></div><div>This is *weird* but it's doable :) In my case, kdev-ruby says that a is of type String, which is correct. This is working in a local branch in which I'm working right now and that I haven't pushed to master yet, but I think that this example works in my master branch as well. So, maybe you might want to take a look at how this situation is handled in kdev-ruby ;-) This is the first thing that it's done in the DeclarationBuilder::visitAssignStatement method. Basically, for each node in the right side of the assignment we visit it through DeclarationBuilderBase and then it's visited by the ExpressionVisitor. I'm sure that this can be further optimized but right now I'm just making sure that everything works. I hope that this helps :)</div>
<div><br></div><div>Greetings,</div><div>Miquel</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-09 12:40 GMT+02:00 Sven Brauch <span dir="ltr"><<a href="mailto:svenbrauch@googlemail.com" target="_blank">svenbrauch@googlemail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<div class=""><br>
On Wednesday 09 April 2014 11:44:33 Denis Steckelmacher wrote:<br>
> var a = function() {<br>
>      var b = 5;<br>
>      return b;<br>
> }<br>
><br>
> This snippet exposes three areas where ExpressionVisitor has<br>
> difficulties to find the type of expressions:<br>
</div>Indeed, you're right. I didn't think about that. That will be ugly to handle<br>
if you want to visit the function as an expression, as you already said.<br>
<br>
Thinking about it, Python has the same problem and solves it by simply not<br>
supporting it. That's not a problem there though, since this syntax can only<br>
be used for functions which only have one statement in their body, and it's<br>
discouraged to assign those to a name so effectively nobody is doing it. In JS<br>
this is obviously different. :(<br>
<br>
Your previous solution seems better suited for this particular case, but you<br>
lose the flexibility to determine the type of an expression outside of the<br>
builders (e.g. for completion) entirely ... so I am unsure how you would do<br>
that in the completion context then (assume you want to do completion on<br>
foo.bar[3].x.<cursor>, if you can't just throw that expression into something<br>
you are using in the analyzer anyways, it will either need a lot of duplicated<br>
functionality or will just not work).<br>
<br>
I see two other solutions:<br>
 1) simply make the declarationbuilder recognize this particular construct and<br>
treat it like function a() { ... }. That's a rather simple solution but it's<br>
not very future-proof, unfortunately, since there are other similar cases with<br>
the same problem most likely. Still, maybe this is what we should do for now<br>
-- it's simple and probably catches almost all cases.<br>
 2) this one I'm not sure about if it would work and it also sounds quite<br>
adventurous: You could in general build function contexts in the expression<br>
visitor. The openContext() method is not needed to instantiate contexts; you<br>
can create a DUContext* yourself, and then return it and open it from the<br>
context builder to merge it with the surrounding code. As said, I don't know<br>
if this would work and whether it would be ugly or not. It's probably not a<br>
good idea.<br>
<br>
Aleix, do you have any bright ideas regarding this?<br>
<br>
Greetings!<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kde.org">KDevelop-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kdevelop-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br></div>