hanchenye-llvm-project/lldb/scripts
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
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
checkpoint-llvm.pl
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
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