diff options
author | Enrico Granata <egranata@apple.com> | 2015-09-01 18:22:39 +0000 |
---|---|---|
committer | Enrico Granata <egranata@apple.com> | 2015-09-01 18:22:39 +0000 |
commit | 980c0484c5f9fb1f4c1266c81418ba63b60e9def (patch) | |
tree | d21527cbd5d0d836e063e7149cdcfd294243594b /lldb/test/python_api/hello_world/TestHelloWorld.py | |
parent | 2df884f95a39b3588324ec2af5903b9eb0ebd162 (diff) | |
download | bcm5719-llvm-980c0484c5f9fb1f4c1266c81418ba63b60e9def.tar.gz bcm5719-llvm-980c0484c5f9fb1f4c1266c81418ba63b60e9def.zip |
Add support for language plugins to provide data formatters (second attempt)
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
Diffstat (limited to 'lldb/test/python_api/hello_world/TestHelloWorld.py')
0 files changed, 0 insertions, 0 deletions