| T O P I C R E V I E W |
| tony.riviere |
Posted - Dec 05 2018 : 06:42:34 AM
Here is the scenario:
I'm writing a call to MyFunc() inside Test() which expect a type which is an alias to a variant.
The tooltip only displays the signature of MyFunc() and I see it expects a MyVariant but so far I ignore what this type really is.
I have to leave my function call, go to the declaration of the function, and put the mouse over the type, and then it displays the alias in the tooltip:
I'd like to see the alias expansion within the 1st tooltip while I'm writing the function call so that I don't have to leave the context. Something like:
|
| 8 L A T E S T R E P L I E S (Newest First) |
| tony.riviere |
Posted - Dec 12 2018 : 08:05:19 AM
Thanks. |
| feline |
Posted - Dec 11 2018 : 08:30:50 AM
There are always going to be some odd edge cases, but it looks like we have a plan here. I have put in a feature request for this:
case=132779 |
| tony.riviere |
Posted - Dec 10 2018 : 08:11:21 AM
Extended tooltip looks fine.
For type expansion, you have also this case:
using MyType = std::conditional_t<condition, int, float>;
Where MyType type will depend on a (compile-time) condition.
Regarding the accuracy, if you don't evaluate preprocessor branches, maybe you can rely on Intellisense information if available? |
| feline |
Posted - Dec 07 2018 : 12:02:10 PM
The "problem" is a half formed thought. I recall some time ago when we had a setting to tell VA to try and evaluate macros more deeply, that you could get odd results if you were using the Qt library, something to do with macros it included for TRUE and FALSE from memory.
A better example of where this might break down is something like this:
#ifdef LINUX
using STRUCT_TYPE CLinuxStringHandling
#else
using STRUCT_TYPE CString
#endif
now what do we expand STRUCT_TYPE to? Currently VA parses all branches. What about different types for DEBUG and RELEASE?
Also what about types where the alias is there to make the type more clear? "wtypes.h" has quite a few different aliases for "void *". They may all be the same underlying type, but the named type is informative.
I actually like the idea, and see how it will help, I am just trying to work out what it will break, and how to handle that.
Perhaps updating the tooltip with the expanded type on a new line below the current signature? Then you have the final "helpfully named" type, and what it is made up of at the same time. |
| tony.riviere |
Posted - Dec 07 2018 : 10:01:23 AM
Is it possible to update or replace the tooltip adding a new line with the expansion? I don't think it's necessary to display another tooltip aside the 1st one.
Actually, I don't know if it takes long time to expand one type (assuming there's no more than 2~3 indirections in general, maybe up to 5 in rare cases)? If it's fast enough, then no need for a timer nor manual trigger.
I'm not sure to understand what would be the problem with built-in aliases and in which way they are "unexpected"? I would consider them the same as the others. |
| feline |
Posted - Dec 07 2018 : 09:34:10 AM
Only expanding the current / bold parameter makes a lot of sense, and keeps this limited in scope, and sensible. Are you thinking of having this happen automatically? So having a second tooltip appear some moments after the first tooltip? This could get visually noisy as you move from one parameter to the next, with the second tooltip disappearing, only to reappear if / when it next has something to report.
Also, what about "built in" aliases, like Windows defining:
#define VOID void
I am just wondering about unexpected expansions, which leaves me thinking having this triggered on demand, for just the current parameter, would make more sense. Then you will know why the tooltip appeared, since you asked for it yourself. |
| tony.riviere |
Posted - Dec 05 2018 : 3:36:21 PM
If the function has many parameters, I would consider only the current one depending on the caret position: only the parameter appearing in bold in the tooltip.
I think the expansion should run recursively until the real type is found and display only this one. If it takes time to query the information, being asynchronous and appearing later is acceptable.
That being said, if we have the following:
using MapKey = std::string;
The tooltip would display:
using MapKey = std::basic_string<char>;
This might be considered as side effect, but still acceptable IMHO if it saves time for all other cases.
Regarding expanding macros, well since I have a bad opinion about macros and don't use them for types, I won't blame you if it's not implemented ^^ But I understand that it may be considered the same as type aliases. |
| feline |
Posted - Dec 05 2018 : 1:34:18 PM
The same problem is going to happen with typedefs, macros, etc. So what you are looking for here is an option to have VA expand any "expandable" type in the tooltip.
Since we have to consider multiple parameters, and the return type as well, there could be several places in the tooltip that could be expanded. Then there is the case where the first level of expansion just gives you another placeholder name...
I have encountered the same problem myself now and then, but I am not sure if a tooltip is the best solution. But having said that, I don't know what a good solution would be. Just expanding one symbol / type one level is easy, but how do we tell VA which one to expand, when there are several to choose from? How deep should the expansion go? |
|
|
