summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/FormattersHelpers.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove even more of the data formatters that silently run codeEnrico Granata2016-04-081-177/+0
| | | | | | Fixes <rdar://problem/25629755> llvm-svn: 265849
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-121-3/+8
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* Upstream some data formatter related cleanupsEnrico Granata2015-11-131-7/+18
| | | | llvm-svn: 253093
* Rationalization of includes in the data formatters codeEnrico Granata2015-10-201-0/+1
| | | | llvm-svn: 250798
* Introduce a variant of GetSummaryAsCString() that takes a LanguageType ↵Enrico Granata2015-10-071-2/+5
| | | | | | | | argument, and use it when crafting summaries by running selectors This is the first in a series of commits that are meant to teach LLDB how to properly handle multi-language formatting of values llvm-svn: 249503
* Fix evaluation of unicode character arrays (char16_t[] and char32_t[])Dawn Perchik2015-09-251-0/+13
| | | | | | | | | | | | | | | | Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
* Add the ability for formatter categories to be bound to one or more languagesEnrico Granata2015-09-171-0/+11
| | | | | | What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages llvm-svn: 247872
* Nuke CXXFormatterFunctions.cpp - split the contents of it across different ↵Enrico Granata2015-09-041-0/+177
| | | | | | | | files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
* Move the functions that FormatManager uses to actually load formatters into ↵Enrico Granata2015-09-021-0/+120
their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
OpenPOWER on IntegriCloud