Commit Graph

8 Commits

Author SHA1 Message Date
Enrico Granata bd5eab8287 Fix a bug where language categories would hold on to their caches even after changes
llvm-svn: 255603
2015-12-15 02:20:48 +00:00
Enrico Granata 8a9a8f3940 Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be
This is a NFC commit that is essentially plumbing the new currency through the system

llvm-svn: 249366
2015-10-06 01:02:47 +00:00
Enrico Granata 7cb59e1a0f Move hardcoded formatters from the FormatManager to the Language plugins
llvm-svn: 247831
2015-09-16 18:28:11 +00:00
Enrico Granata 170c395e70 Move Objective-C data formatters to the Objective-C language plugin where they belong
llvm-svn: 247627
2015-09-14 22:18:32 +00:00
Enrico Granata 33e97e63a5 Move the C++ data formatters to the C++ language plugin
llvm-svn: 246873
2015-09-04 21:01:18 +00:00
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