In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image lookup -t"
-> The corresponding testcase.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
See inlined comments.
| source/Commands/CommandObjectTarget.cpp | ||
|---|---|---|
| 1911–1943 | I would rather see this promotion of the correct types happen inside Module::FindTypes() so that we don't need to do this everywhere. Any types that are returned in the type list should be ordered such that the first item in the list of the most important and correct choice for the SymbolContext that was provided. When checking the symbol context block, we also need to check the parent blocks and stop when we run into a block that has inlined function info. So the solution in Module::FindTypes() should probably pass the resulting unsorted TypeList with all types to a new SymbolContext function: TypeList SymbolContext::SortTypeList (const TypeList& type_list); The block in the symbol context might be the deepest block in a function: int main(int argc, char **argv)
{
if (argc)
{
if (argv[argc])
{ // <<< SymbolContextBlock might be this one
}
}
}So we will need to check for the best block as a type could be defined just inside main, or inside the "if (argc)" block or inside the "if (argv[argc])" block. There is a function on a block where you can check if a block contains another block as a child: bool Block::Contains (const Block *block) const; Because you might end up with code where a type is defined in a block in a function, but it isn't contained in any parent blocks of the current block... So the type list ordering should be:
| |
Comment Actions
The TypeList is a multimap that uses the USERID as the key, so the order in which the types would be stored is always fixed and sorting may not be useful. I can make modifications for Inlined functions ?.
Comment Actions
Very close, we just need the FindTypes_Impl to be left as they were (but switch over to using TypeMap, and then have the Module::FindTypes() and ModuleList::FindTypes() do the actual sorting before the results are returned.
| source/Core/Module.cpp | ||
|---|---|---|
| 949–956 | indents should be four spaces on all these. You also have to watch out for the "append" argument and do the right thing if it is "true" and append any matches from "typesmap". Also, the _Impl versions of these functions should be left as is, no changes except that it should use TypeMap like it was before, but then the places that call this _Impl should then do the sorting. The issue is Module has FindTypes(...) and ModuleList also have FindTypes(...). Each of these FindTypes() functions calls the _Impl versions, and they should be the ones that do the final sorting after all results have been gathered. | |
| source/Symbol/TypeList.cpp | ||
| 44–47 | Go ahead and remove this function. | |
| 125–126 | Remove this. | |
Comment Actions
I reverted this in revision 248421 because it was causing breakages in the test suite.
For future reference, please remember to run the test suite before committing changes.
I would rather see this promotion of the correct types happen inside Module::FindTypes() so that we don't need to do this everywhere.
Any types that are returned in the type list should be ordered such that the first item in the list of the most important and correct choice for the SymbolContext that was provided.
When checking the symbol context block, we also need to check the parent blocks and stop when we run into a block that has inlined function info. So the solution in Module::FindTypes() should probably pass the resulting unsorted TypeList with all types to a new SymbolContext function:
The block in the symbol context might be the deepest block in a function:
int main(int argc, char **argv) { if (argc) { if (argv[argc]) { // <<< SymbolContextBlock might be this one } } }So we will need to check for the best block as a type could be defined just inside main, or inside the "if (argc)" block or inside the "if (argv[argc])" block.
There is a function on a block where you can check if a block contains another block as a child:
Because you might end up with code where a type is defined in a block in a function, but it isn't contained in any parent blocks of the current block...
So the type list ordering should be: