Commit Graph

5 Commits

Author SHA1 Message Date
Enrico Granata 980c0484c5 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
2015-09-01 18:22:39 +00:00
Pavel Labath f15a16704b Revert "Add support for language plugins to provide data formatters"
This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests.

llvm-svn: 246536
2015-09-01 09:02:54 +00:00
Enrico Granata 2233895a3b Add support for language plugins to provide data formatters
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: 246515
2015-09-01 01:01:48 +00:00
Enrico Granata 2996d8236c Include <mutex>
llvm-svn: 246222
2015-08-27 22:14:06 +00:00
Enrico Granata 5f9d310640 Add a new type of plugin: Language plugin
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin

The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation

At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++

llvm-svn: 246212
2015-08-27 21:33:50 +00:00