summaryrefslogtreecommitdiffstats
path: root/lldb/test/python_api/hello_world/TestHelloWorld.py
diff options
context:
space:
mode:
authorEnrico Granata <egranata@apple.com>2015-09-01 18:22:39 +0000
committerEnrico Granata <egranata@apple.com>2015-09-01 18:22:39 +0000
commit980c0484c5f9fb1f4c1266c81418ba63b60e9def (patch)
treed21527cbd5d0d836e063e7149cdcfd294243594b /lldb/test/python_api/hello_world/TestHelloWorld.py
parent2df884f95a39b3588324ec2af5903b9eb0ebd162 (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud