summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Language.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-111-5/+0
| | | | | | | | 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
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-17/+7
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-7/+17
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-17/+7
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* [Target] Introduce Process::GetLanguageRuntimesAlex Langford2019-05-291-0/+9
| | | | | | | | | | | | | | | | Summary: Currently there's not really a good way to iterate over the language runtimes a process has. This is sometimes desirable (as seen in my change to Thread). Additionally, there's not really a good reason to iterate over every available language, but rather only over languages for which we have a plugin loaded. Reviewers: JDevlieghere, davide, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62562 llvm-svn: 361999
* Factor out switch statement into a helper function (NFC)Adrian Prantl2019-05-161-0/+18
| | | | | | This addresses post-commit review feedback for https://reviews.llvm.org/D62015. llvm-svn: 360930
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-4/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-1/+1
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* 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
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-141-2/+1
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [LLDB] Added syntax highlighting supportRaphael Isemann2018-08-021-0/+32
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed to use colors), printed source code is annotated with the ANSI color escape sequences. So far we have only one highlighter which is based on Clang and is responsible for all languages that are supported by Clang. It essentially just runs the raw lexer over the input and then surrounds the specific tokens with the configured escape sequences. Reviewers: zturner, davide Reviewed By: davide Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D49334 llvm-svn: 338662
* Rename Error -> Status.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Switch std::call_once to llvm::call_onceKamil Rytarowski2017-02-061-4/+6
| | | | | | | | | | | | | | | | | | | | | Summary: The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms. This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg, emaste, mehdi_amini, clayborg Reviewed By: labath, clayborg Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29288 llvm-svn: 294202
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Implement a general type scavenger that can dig types from debug info + a ↵Enrico Granata2016-11-011-0/+33
| | | | | | | | | | filtering mechanism to accept/reject results thusly obtained Implement the C++ type lookup support in terms of this general scavenger The idea is that we may want other languages to do debug info based search (exclusively, or as an add-on to runtime/module based searching) and it makes sense to avoid duplicating this functionality llvm-svn: 285727
* Update OptionGroup::SetValue to take StringRef.Zachary Turner2016-09-231-4/+0
| | | | | | | | Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
* Convert many functions to use StringRefs.Zachary Turner2016-09-171-4/+9
| | | | | | | | | | | | | Where possible, remove the const char* version. To keep the risk and impact here minimal, I've only done the simplest functions. In the process, I found a few opportunities for adding some unit tests, so I added those as well. Tested on Windows, Linux, and OSX. llvm-svn: 281799
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-373/+297
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-1/+0
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-8/+8
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Make it possible for language plugins to provide additional custom help for ↵Enrico Granata2016-03-241-0/+6
| | | | | | 'type lookup' llvm-svn: 264356
* Objective-C++ is a kind of C++.Sean Callanan2016-02-121-0/+1
| | | | llvm-svn: 260715
* Fix formatting for last commit.Jim Ingham2015-12-181-3/+3
| | | | llvm-svn: 255973
* Make the Language print the description of the Exception Breakpoint ↵Jim Ingham2015-12-181-0/+13
| | | | | | | | | | | resolver. Also have the breakpoint description print the precondition description if one exists. No behavior change. <rdar://problem/22885189> llvm-svn: 255972
* Rework breakpoint language filtering to use the symbol context's language.Dawn Perchik2015-12-161-0/+51
| | | | | | | | | | | | | | | | This patch reworks the breakpoint filter-by-language patch to use the symbol context instead of trying to guess the language solely from the symbol's name. This has the advantage that symbols compiled with debug info will have their actual language known. Symbols without debug info will still do the same "guess"ing because Symbol::GetLanguage() is implemented using Mangled::GuessLanguage(). The recognition of ObjC names was merged into Mangled::GuessLanguage. Reviewed by: jingham, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15326 llvm-svn: 255808
* Pass the ExecutionContext as well, since it is actually usefulEnrico Granata2015-11-191-0/+1
| | | | llvm-svn: 253537
* Allow the language plugins a say in how the function name is rendered as ↵Enrico Granata2015-11-191-0/+8
| | | | | | part of frame formatting llvm-svn: 253531
* Introduce a way for Languages to specify whether values of "reference types" ↵Enrico Granata2015-11-101-0/+12
| | | | | | | | | | are "nil" (not pointing to anything) or uninitialized (never made to point at anything) This latter determination may or may not be possible on a per-language basis; and neither is mandatory to implement for any language Use this knowledge in the ValueObjectPrinter to generalize the notion of IsObjCNil() and the respective printout llvm-svn: 252663
* Change ValueObject::IsLogicalTrue so that it starts by asking the applicable ↵Enrico Granata2015-11-021-0/+7
| | | | | | Language plugin before using the C-style rule llvm-svn: 251838
* Fixed version of r250913, which actually implements all the static functions.Sean Callanan2015-10-211-0/+11
| | | | | | Thanks to Siva Chandra and Oleksiy Vyalov for pouncing on this. llvm-svn: 250928
* Revert "Made the REPL choose a default language if only one REPL can be chosen."Siva Chandra2015-10-211-11/+0
| | | | | | | | | | | | Summary: This reverts commit babd6dd74e316b1fcd9d171d7d8c83845d51a487. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13952 llvm-svn: 250927
* Made the REPL choose a default language if only one REPL can be chosen.Sean Callanan2015-10-211-0/+11
| | | | | | This requires REPLs to enumerate the languages they support. llvm-svn: 250913
* Let Language plugins vend a default DeclPrintingHelper in case a custom one ↵Enrico Granata2015-10-191-0/+6
| | | | | | is not specified for the specific invocation llvm-svn: 250744
* Added support for enumerating the languages that actually support TypeSystemsSean Callanan2015-10-081-0/+12
| | | | | | | and expressions. Also wired that into the OptionValue infrastructure, although it isn't used for tab-completion yet. llvm-svn: 249769
* This is the work I was building up to with my patches yesterdayEnrico Granata2015-10-071-0/+7
| | | | | | | | | Introduce the notion of Language-based formatter prefix/suffix This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this llvm-svn: 249587
* Add a 'type lookup' command. This command is meant to look up type ↵Enrico Granata2015-10-011-0/+28
| | | | | | | | | | information by name in a language-specific way. Currently, it only supports Objective-C - C++ types can be looked up through debug info via 'image lookup -t', whereas ObjC types via this command are looked up by runtime introspection This behavior is in line with type lookup's behavior in Xcode 7, but I am definitely open to feedback as to what makes the most sense here llvm-svn: 249047
* Introudce a IsTopLevelFunction() API on Language and FunctionEnrico Granata2015-09-301-0/+6
| | | | | | | | This is meant to support languages that have a scripting mode with top-level code that acts as global For now, this flag only controls whether 'frame variable' will attempt to treat globals as locals when within such a function llvm-svn: 248960
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-161-0/+24
| | | | llvm-svn: 247831
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-091-0/+7
| | | | | | | | notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
* Data formatter candidate matches can be generated in a number of ways; ↵Enrico Granata2015-09-091-0/+6
| | | | | | | | | | language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
* Add a Language::ForAllLanguages helper functionEnrico Granata2015-09-021-0/+10
| | | | llvm-svn: 246614
* Move things from the LanguageRuntime that obviously belong in the new ↵Jim Ingham2015-09-021-0/+141
| | | | | | Language plugin instead. llvm-svn: 246611
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-0/+6
| | | | | | | | | | | | | | | | | 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-6/+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/+6
| | | | | | | | | | | | | | | | | 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
* Include <mutex>Enrico Granata2015-08-271-0/+1
| | | | llvm-svn: 246222
* Add a new type of plugin: Language pluginEnrico Granata2015-08-271-0/+101
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
OpenPOWER on IntegriCloud