Review Request 117535: If a function contains several return statements of different types, build an UnsureType

[Sven Brauch]

> On April 13, 2014, 12:38 p.m., Sven Brauch wrote:
> > duchain/helper.cpp, line 55
> > <https://git.reviewboard.kde.org/r/117535/diff/1/?file=265119#file265119line55>
> >
> >     Definitely not the right thing to do. Don't discard the information you have. You can either do unsure(mixed, T) or just T, I would go for the latter, but definitely not just mixed.
> >     
> >     mixed is the analyzer admitting complete defeat and is entirely useless. Avoid it at all costs.
> 
> Denis Steckelmacher wrote:
>     If a function can return unsure(mixed, T), I would not say that it returns T because the user will then expect that the function will always return T, which is not the case. Maybe unsure(mixed, T) is the solution, if you don't want to lose the T. My view was that if the analyzer doesn't know the type of one return statement, then it doesn't know the return type of the function, even if other return statements have a definite type. Moreover, if the user assigns a "mixed" value to a variable, then the variable can be of any type, even if it sometimes receives a value of type T.

Let me cite an example from the python world: http://i.imgur.com/bKLZMdF.png. The analyzer doesn't know the content types of self.keys, self.values, or self.comments. Still, the return type it deduces is completely correct because the if ... else "err". Your method would return "mixed" here -- a huge loss.

What you have to keep in mind is that your analyzer doesn't know anything anyways. The user could always do funny runtime behaviour and completely screw everything up. So the best it can do is provide a reasonable guess. And if you can determine that the function returns T in one place, then it's a reasonable guess that the function returns T. Yes, this might not be the full truth, but the user will have to cope with that.


- Sven


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117535/#review55584
-----------------------------------------------------------


On April 13, 2014, 12:17 p.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117535/
> -----------------------------------------------------------
> 
> (Updated April 13, 2014, 12:17 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> This patch introduces the mergeTypes() function, based on the same function in kdev-python. Its behavior differs from the Python one in several aspects, though:
> 
> * Mixed types absorb other types (the function never returns "unsure(mixed, int)", but simply "mixed"). I'm not sure that it is the right thing to do, but I think that the "mixed" type is generally used to represent an unknown type. The user therefore gains no information by knowing that a function returns "anything, and this anything can sometimes be an int".
> * The function makes more assumptions than the Python one. For instance, I know that the second type passed to it is never NULL, and that the function will be used to add a return type to a function or to add a type of a variable.
> 
> This function is used to merge the type of all the return statements of a function. This way, the user can know when a function may return values of different types. A future patch will also use this function to deduce the type of variables using assignments to them. 
> 
> 
> Diffs
> -----
> 
>   duchain/declarationbuilder.cpp fe131ce 
>   duchain/helper.h 23a6d0e 
>   duchain/helper.cpp 3ffdd56 
>   tests/files/helloworld.js 1ce3815 
> 
> Diff: https://git.reviewboard.kde.org/r/117535/diff/
> 
> 
> Testing
> -------
> 
> 4 tests have been added. They test the basic features of mergeTypes and some corner cases (how voids should be handled, different return statements having the same type and how mixed should take precedence over other types).
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

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