Open andocz opened 2 years ago
I realized this happens because template specializations are considered separate entities. So technically what we're seeing is correct, but I don't think it's a very good UI. It would be easier to read if specializations were grouped together in some way.
I think the best way to do this would be to have a toggle for displaying a less detailed tree where they are not differentiated at all. Another solution would be to group them into expandable nodes, but that may lead to a very cluttered tree.
Currently the database seems to lack any information about templates, so that would probably have to be added.
Thanks for the discovery. We had a long debate on how to visualize templates - show the source or the instantiations. Actually, this is tricky, because instantiations of different templates may result different AST subtree, eg, when using "if constexpr" or similar. However, the "average" case is usually is not that complex. Before we decide here, perhaps we should check how some tools (e.g. understand or woboq works.
Wouldn't it be enough to aggregate references? For example, if myfunc<A>()
calls a()
and myfunc<B>()
calls b1()
and b2()
, then querying the callees of myfunc<>()
would return [a(), b1(), b2()]
.
I checked Understand, Woboq and Visual Studio 2019, and they completely ignore template specializations. When listing usages/callers/callees, they treat template functions and classes as if the part between <>
wasn't there. Understand has a "Template parameters" node in its info tree which lists the generic template parameter types of a template, that's all I could find for support.
Maybe we could ignore specializations too, unless we are viewing the info tree of a template function/class. Then we'd show a "Specializations" node, the children of which are the info tree of each specialization (your idea from an earlier meeting). This way the specializations would only be seen when we're fully "zoomed in" to the template function/class. Showing them in other situations would be unnecessary clutter, I think.
Sometimes there are duplicate nodes in the info tree.
For example,
tinyxml2::DynArray::Push
has the following code:But in the info tree, it is shown as calling
EnsureCapacity
9 times (should be 1), and being called bytinyxml2::MemPoolT::Alloc
5 times (should also be 1). Also, all the usages are listed twice. All of these duplicates have the same line number.Info Tree
![image](https://user-images.githubusercontent.com/100377984/156955260-4478185b-58e8-4961-a7f0-7db7dc2450c3.png)This might be related to https://github.com/Ericsson/CodeCompass/issues/544.Actually, they're unrelated.