summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/LanguageCategory.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [LLDB] Fix compilation with GCC 5Martin Storsjö2020-02-061-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D74084 (cherry picked from commit 5bbaf543585c54868f8a2bdd9e74edcf395b24b3)
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-111-16/+3
| | | | | | | | This is a half-implemented feature that as far as we can tell was never used by anything since its original inclusion in 2014. This patch removes it to make remaining the code easier to understand. Differential Revision: https://reviews.llvm.org/D71310
* Remove unsound caching in LanguageCategoryAdrian Prantl2019-12-101-4/+0
| | | | | | | | Analogous to https://reviews.llvm.org/D71233 it is not safe to cache something that depends on the actual ValueObject in a cache then keys only off the type name. Differential Revision: https://reviews.llvm.org/D71297
* Replace redundant code in LanguageCategory with templates (NFC)Adrian Prantl2019-12-101-132/+55
| | | | Differential Revision: https://reviews.llvm.org/D71296
* [DataFormatters] Change the Get() method to take a LanguageType.Davide Italiano2019-12-101-8/+8
| | | | Suggested by Adrian.
* Replace redundant code in FormatManager and FormatCache with templates (NFC)Adrian Prantl2019-12-101-12/+12
| | | | | | | | | | | | | | | This is a preparatory patch for an upcoming bugfix. FormatManager and friends have four identical implementations of many accessor functions to deal with the four types of shared pointers in the FormatCache. This patch replaces these implementations with templates. While this patch drastically reduces the amount of source code and its maintainablity, it doesn't actually improve code size. I'd argue, this is still an improvement. rdar://problem/57756763 Differential Revision: https://reviews.llvm.org/D71231
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-221/+182
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix a bug where language categories would hold on to their caches even after ↵Enrico Granata2015-12-151-0/+6
| | | | | | changes llvm-svn: 255603
* Introduce a FormattersMatchData class which contains all the information ↵Enrico Granata2015-10-061-62/+58
| | | | | | | | 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
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-161-7/+117
| | | | llvm-svn: 247831
* Move Objective-C data formatters to the Objective-C language plugin where ↵Enrico Granata2015-09-141-4/+4
| | | | | | they belong llvm-svn: 247627
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-041-0/+26
| | | | llvm-svn: 246873
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-0/+133
| | | | | | | | | | | | | | | | | 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
* Revert "Add support for language plugins to provide data formatters"Pavel Labath2015-09-011-133/+0
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* Add support for language plugins to provide data formattersEnrico Granata2015-09-011-0/+133
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
OpenPOWER on IntegriCloud