summaryrefslogtreecommitdiffstats
path: root/lldb/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-227-43/+52
| | | | | | | | | | | | | | | | | | | 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-226-44/+43
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Add missing includeAdrian Prantl2019-08-221-0/+1
| | | | llvm-svn: 369692
* Add missing includeAdrian Prantl2019-08-221-0/+1
| | | | llvm-svn: 369691
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-226-43/+44
| | | | | | | | | | | | | | | | | 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
* Doxygenify comments.Adrian Prantl2019-08-221-279/+297
| | | | llvm-svn: 369669
* [lldb][NFC] Remove unused return value from HandleOptionArgumentCompletionRaphael Isemann2019-08-221-8/+1
| | | | llvm-svn: 369635
* [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann2019-08-2221-109/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
* [lldb] Replace std::once_flag with llvm::once_flag.Davide Italiano2019-08-221-1/+2
| | | | | | | | | | | | | | | | Summary: The former seems like it's not working on some platforms. All the other uses use `llvm::`, so, let's change for consistency. Reviewers: jasonmolenda, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66566 llvm-svn: 369618
* Add char8_t support (C++20)Jonas Devlieghere2019-08-211-1/+2
| | | | | | | | | | | | This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-213-19/+31
| | | | | | | | | | | | | | | This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
* [Symbol] Remove unused clang headers from TypeAlex Langford2019-08-211-1/+0
| | | | llvm-svn: 369494
* [NFC] Return llvm::StringRef from StringExtractor::GetStringRef.Jonas Devlieghere2019-08-211-3/+1
| | | | | | | | | | This patch removes the two variant of StringExtractor::GetStringRef that return (non-)const references to std::string. The non-const one was being abused to reinitialize the StringExtractor and its uses are replaced by calls to the copy asignment operator. The const variant was refactored to return an actual llvm::StringRef. llvm-svn: 369493
* [NFC] Remove unused function GetHexWithFixedSizeJonas Devlieghere2019-08-211-9/+8
| | | | | | | | The implementation of this function was obviously incorrect, as the result variable was never used. This led me to check if it was actually used anywhere, which came back negative. llvm-svn: 369492
* [NFC] Remove lldb_utility namespace.Jonas Devlieghere2019-08-213-5/+5
| | | | | | | While generating the Doxygen I noticed this lone namespace that has one class and one function in it. This moves them into lldb_private. llvm-svn: 369485
* [NFC] Fix -Wdocumentation warnings in Utility.Jonas Devlieghere2019-08-207-80/+61
| | | | | | | | This patch fixes a bunch of -Wdocumentation warnings in Utility. I'm sure there are still a bunch outdated comments left, but this fixes the most flagrant inconsistencies that the compiler understands. llvm-svn: 369461
* [Symbol] Move VerifyDecl to ClangASTContextAlex Langford2019-08-201-18/+0
| | | | | | VerifyDecl is specific to clang and is only used in ClangASTContext. llvm-svn: 369456
* [NFC] Update RegularExpression documentationJonas Devlieghere2019-08-201-21/+14
| | | | llvm-svn: 369452
* [ClangExpressionParser] Add ClangDeclVendorAlex Langford2019-08-201-10/+11
| | | | | | | | | | | | | | | | Summary: This introduces a layer between DeclVendor and the currently implemented DeclVendors (ClangModulesDeclVendor and AppleObjCDeclVendor). This allows the removal of DeclVendor::GetImporterSource which is extremely clang-specific, freeing up the interface to be more general. A good follow up to this would be to remove the remaining instances of clang in DeclVendor, either by moving things to ClangDeclVendor or by using wrappers (e.g. CompilerDecl instead of clang::NamedDecl). Differential Revision: https://reviews.llvm.org/D66451 llvm-svn: 369424
* [lldb] D66174 `RegularExpression` cleanupJan Kratochvil2019-08-202-18/+13
| | | | | | | | | | I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex. Differential Revision: https://reviews.llvm.org/D66392 llvm-svn: 369352
* [lldb] Fix typo on the BreakpointLocation header and the lldbtest.py (NFC)Med Ismail Bennani2019-08-192-14/+33
| | | | | | | | | | | | | | | Summary: This commit fixes some typo I found while exploring LLDB's codebase. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66452 llvm-svn: 369313
* [lldb][NFC] Remove StringList::AutoCompleteRaphael Isemann2019-08-191-8/+0
| | | | | | | We don't need this very specific function in StringList that we only call once in LLDB. llvm-svn: 369242
* [lldb][NFC] Address review comments to StringList for-loop supportRaphael Isemann2019-08-191-4/+4
| | | | llvm-svn: 369237
* [lldb] Remove unused inheritance in RegularExpressionJan Kratochvil2019-08-191-1/+1
| | | | | | | | D66174 left inherited llvm::Regex which is now a member variable there. Approved as a part of: https://reviews.llvm.org/D66392#1634575 llvm-svn: 369235
* [Utility] Reimplement RegularExpression on top of llvm::RegexJonas Devlieghere2019-08-165-121/+28
| | | | | | | | | | | | | | | Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I noticed that there are several places where need the regular expression string. So instead I propose to keep the RegularExpression class and make it a thin wrapper around llvm::Regex. This patch also removes the workaround for empty regular expressions. The result is that we are now (more or less) POSIX conformant. Differential revision: https://reviews.llvm.org/D66174 llvm-svn: 369153
* [lldb][NFC] Allow for-ranges on StringListRaphael Isemann2019-08-162-3/+13
| | | | llvm-svn: 369113
* Stop-hooks weren't getting called on step-out. Fix that.Jim Ingham2019-08-151-0/+11
| | | | | | | | | | | | | | | | There was a little bit of logic in the StopInfoBreakpoint::PerformAction that would null out the StopInfo once we had a completed plan so that the next call to GetStopInfo would replace it with the StopInfoThreadPlan. But the stop-hooks check for whether a thread stopped for a reason didn't trigger this conversion. So I added an API to do that directly, and then called it where before we just reset the StopInfo. <rdar://problem/54270767> Differential Revision: https://reviews.llvm.org/D66241 llvm-svn: 369052
* [lldb][NFC] Refactor remaining completion logic to use CompletionRequestsRaphael Isemann2019-08-155-33/+17
| | | | | | | | | | | | | | | | | | | | This patch moves the remaining completion functions from the old completion API (that used several variables) to just passing a single CompletionRequest. This is for the most part a simple change as we just replace the old arguments with a single CompletionRequest argument. There are a few places where I had to create new CompletionRequests in the called functions as CompletionRequests itself are immutable and don't expose their internal match list anymore. This means that if a function wanted to change the CompletionRequest or directly access the result list, we need to work around this by creating a new CompletionRequest and a temporary match/description list. Preparation work for rdar://53769355 llvm-svn: 369000
* [NFC] Fix documentation for some utility classes.Jonas Devlieghere2019-08-152-31/+24
| | | | | | This fixes a few warnings emitted when compiling with -Wdocumentation. llvm-svn: 368959
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-142-3/+3
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* Add missing SetID method to fix Windows buildAaron Smith2019-08-141-0/+2
| | | | llvm-svn: 368852
* [DWARF} Use LLVM's debug line parser in LLDB.Jonas Devlieghere2019-08-132-2/+8
| | | | | | | | | | | | | | | | The line number table header was substantially revised in DWARF 5 and is not fully supported by LLDB's current debug line implementation. This patch replaces the LLDB debug line parser with its counterpart in LLVM. This was possible because of the limited contact surface between the code to parse the DWARF debug line section and the rest of LLDB. We pay a small cost in terms of performance and memory usage. This is something we plan to address in the near future. Differential revision: https://reviews.llvm.org/D62570 llvm-svn: 368742
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-132-5/+2
| | | | | | | | | | Summary: Ideally CompilerType would have no knowledge of clang or any individual TypeSystem. Decoupling clang is relatively straightforward. Differential Revision: https://reviews.llvm.org/D66102 llvm-svn: 368741
* [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.Davide Italiano2019-08-123-3/+5
| | | | llvm-svn: 368620
* [Symbol] GetTypeBitAlign() should return None in case of failure.Davide Italiano2019-08-123-3/+5
| | | | | | | | | | | | | | | | Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
* [lldb][NFC] Minor fixes for lldb_private::DiagnosticManagerRaphael Isemann2019-08-121-4/+2
| | | | llvm-svn: 368582
* [lldb] Remove undocumented return value from DiagnosticManager::PutStringRaphael Isemann2019-08-121-1/+1
| | | | | | | | | | | The returned value is currently unused. It also seems to imply that it somehow represents 'printf-style' the number of characters/bytes written to some output stream (which is incorrect, as we only know the actual size of the written message when we have rendered it, e.g. via GetString and DiagnosticManagers have no associated output stream). llvm-svn: 368577
* Remove unused and undocumented data_offset parameter (NFC)Adrian Prantl2019-08-081-1/+0
| | | | | | | | | Value::GetValueAsData() takes an undocumented parameter called data_offset that is always 0. Differential Revision: https://reviews.llvm.org/D65910 llvm-svn: 368330
* Remove xcode-specific Config.hPavel Labath2019-08-081-38/+0
| | | | | | | | | | | | | | | | | | Summary: Now that the xcode project is removed, we no longer need/use the hand-maintained Config.h file, as everything is configured through cmake. This patch deletes that file and reverts some of the changes from r300372, which were made to support this use case. Reviewers: sgraenitz, beanz Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65862 llvm-svn: 368266
* Remove Module::GetSymbolVendorPavel Labath2019-08-081-31/+23
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymbolVendor function, and the various mentions of the SymbolVendor in the Module class. The implementation of GetSymbolVendor is "inlined" into the GetSymbolFile class which I created earlier. After this patch, the SymbolVendor class still exists inside the Module object, but only as an implementation detail -- a fancy holder for the SymbolFile. That will be removed in the next patch. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D65864 llvm-svn: 368263
* [Materializer] Remove wrong SetSizeAndAlignmentFromType().Davide Italiano2019-08-081-2/+0
| | | | | | | | | | | | This function is unused. It's also wrong, because it computes the size and the alignment of the type without asking the runtime, so it doesn't work for any language that has one (e.g. swift). One could consider re-implementing this passing an execution scope context, and modifying GetTypeBitAlign() to do the right thing, but given there are no uses, it's not really useful. llvm-svn: 368249
* [Utility] Remove unused function 'GetMatchSpanningIndices'Jonas Devlieghere2019-08-081-4/+0
| | | | llvm-svn: 368243
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-072-2/+5
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* [lldb][NFC] Minor refactorings to (Clang)ExpressionSourceCodeRaphael Isemann2019-08-061-5/+12
| | | | llvm-svn: 368082
* Various build fixes for lldb on MinGWHaibo Huang2019-08-061-0/+13
| | | | | | | | | | Subscribers: mstorsjo, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65691 llvm-svn: 368069
* SymbolVendor: Remove passthrough methodsPavel Labath2019-08-061-81/+0
| | | | | | | | | | After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo(). llvm-svn: 368001
* Revert "[CompilerType] Simplify the interface a bit more.."Davide Italiano2019-08-062-0/+16
| | | | | | | | There's actually a test downstream that fails with this. I think we can still get rid of it, but I need to do some work there first. llvm-svn: 367963
* [CompilerType] Simplify the interface a bit more..Davide Italiano2019-08-062-16/+0
| | | | | | | | | | | | | | | | | | | | | | Summary: .. removing IsMeaninglessWithoutTypeResolution(). I'm fairly confident this was introduced to support swift, where static types [without dynamic counterpart] don't carry a lot of value. Since then, the formatters and dynamic type resolution has been rewritten, and we employ different solutions. This function is unused here too, so let's get read of it. <rdar://problem/36377967> Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65782 llvm-svn: 367957
* [CompilerType] Remove an unused function.Davide Italiano2019-08-053-19/+0
| | | | | | | | | | | | | | | | | | Summary: This simplifies the interface, as I'm trying to understand how we can upstream swift support. <rdar://problem/36377967> Reviewers: teemperor, JDevlieghere, xiaobai, compnerd, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65781 llvm-svn: 367946
* [lldb][NFC] Clang format GetNextPersistentVariableName signatureRaphael Isemann2019-08-051-1/+1
| | | | llvm-svn: 367843
OpenPOWER on IntegriCloud