maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/scripts
History
Enrico Granata e8daa2f843 Introduce the concept of a "display name" for types 
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code

Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice

The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type

Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters

llvm-svn: 209072
 		2014-05-17 19:14:17 +00:00
..
Python Introduce the concept of a "display name" for types 2014-05-17 19:14:17 +00:00
CMakeLists.txt If CMake finds a python interpreter, use it 2014-04-24 16:18:21 +00:00
Makefile Suppress python readline module under Linux to fix a seg fault. 2014-02-26 07:39:20 +00:00
build-lldb-llvm-clang <rdar://problem/10507811> 2012-01-04 22:56:43 +00:00
build-llvm.pl Remove print statements I was using to debug this script additions. 2014-04-24 22:05:25 +00:00
build-swig-wrapper-classes.sh Linux buildbot fix: detect swig tool from PATH in shell script (before searching hardcoded directories) 2012-11-28 23:49:11 +00:00
buildbot.py Added a buildbot script that automatically checks 2011-10-14 21:43:51 +00:00
checkpoint-llvm.pl Updated LLVM/Clang to pick up a fix for imports of 2011-11-04 22:46:46 +00:00
disasm-gdb-remote.pl Fixed register dumping for contained-regs. 2013-02-01 00:45:52 +00:00
finish-swig-wrapper-classes.sh Fixed Makefile-based install to place python packages in the LLDB install tree. 2013-12-06 23:16:23 +00:00
generate-vers.pl Make lldb build with Makefiles on OS X. 2014-01-18 08:05:32 +00:00
install-lldb.sh
…
lldb.swig Merging the iohandler branch back into main. 2014-01-27 23:43:24 +00:00
lldb_python_module.cmake Honour DESTDIR when installing LLDB python module 2014-04-23 12:59:28 +00:00
sed-sources Switched over to using the new lldb::SharingPtr from Howard Hinnant. 2010-06-12 17:45:57 +00:00
verify_api.py Added the ability to verify the LLDB API on MacOSX using a script. Usage is: 2012-08-30 21:21:24 +00:00