summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Symbol
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Fix TestClangASTContext.TestFunctionTemplateInRecordConstruction in ↵Raphael Isemann2020-01-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Debug builds Summary: In Debug builds we call VerifyDecl in ClangASTContext::CreateFunctionDeclaration which in turn calls `getAccess` on the created FunctionDecl. As we passed in a RecordDecl as the DeclContext for the FunctionDecl, we end up hitting the assert in `getAccess` that checks that we never have a Decl inside a Record without a valid AccessSpecifier. FunctionDecls are never in RecordDecls (that would be a CXXMethodDecl) so setting a access specifier would not be the correct way to fix this. Instead this patch does the same thing that DWARFASTParserClang::ParseSubroutine is doing: We pass in the FunctionDecl with the TranslationUnit as the DeclContext. That's not ideal but it is how we currently do it when creating our debug info AST, so the unit test should do the same. Reviewers: shafik Reviewed By: shafik Subscribers: aprantl, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72359
* [lldb][NFC] Take a llvm::Triple in ClangASTContext constructorRaphael Isemann2020-01-071-2/+1
| | | | | | This constructor is supposed to take a string representing an llvm::Triple. We might as well take a llvm::Triple here which saves us all the string conversions in the call sites and we make this more type safe.
* [lldb] Fix crash in AccessDeclContextSanity when copying ↵Raphael Isemann2020-01-021-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | FunctionTemplateDecl inside a record. Summary: We currently don't set access specifiers for function template declarations. This seems to be fine as long as the function template is not declared inside any record in which case Clang asserts with the following once we try to query it's access: ``` Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity, ``` This patch just marks these function template declarations as public to make Clang happy. Reviewers: shafik, teemperor Reviewed By: teemperor Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71909
* [lldb] Add a SubsystemRAII that takes care of calling Initialize and ↵Raphael Isemann2019-12-235-53/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
* [lldb][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-231-2/+1
| | | | | | | | | | | | | | | The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly convert all pointers to clang::DeclContext*. This causes that we for example can't just pass a TranslationUnitDecl* to the constructor without first casting it to its parent class (as it inherits from both Decl and DeclContext so the void* pointer is actually a Decl*). This patch introduces a utility function in the ClangASTContext which gets rid of the requirement to cast all pointers to clang::DeclContext. Also moves all constructor calls to use this function instead which is NFC (beside the change in DWARFASTParserClangTests.cpp).
* [lldb][NFC] Return a reference from ClangASTContext::getASTContext and ↵Raphael Isemann2019-12-212-75/+75
| | | | | | | | | | | remove dead nullptr checks ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a while that the ASTContext is not a nullptr. This causes that we still have a lot of code that is doing nullptr checks on the result of getASTContext() which is all unreachable code. This patch changes the return value to a reference to make it clear this can't be a nullptr and deletes all the nullptr checks.
* [lldb][NFC] Remove utility methods in TestClangASTImporterRaphael Isemann2019-12-201-35/+8
| | | | | We have a central header for all these methods so we can just use those for creating ClangASTContexts.
* [lldb][NFC] Remove redundant ASTContext args to CopyDecl/DeportDeclRaphael Isemann2019-12-201-12/+6
| | | | | | We already pass a Decl here and the additional ASTContext needs to match the Decl. We might as well just pass the Decl and then extract the ASTContext from that.
* [lldb][NFC] Move utility functions from ClangASTImporter and ↵Raphael Isemann2019-12-201-64/+44
| | | | ClangExpressionDeclMap to own header
* [lldb] Add tests for ClangASTImporter's DeportType and DeportDecl methodsRaphael Isemann2019-12-201-11/+82
|
* [lldb][NFC] Use StringRef in CreateRecordType and CreateObjCClassRaphael Isemann2019-12-171-1/+1
|
* [lldb][NFC] Rename ClangASTImporter::InsertRecordDecl to SetRecordLayout and ↵Raphael Isemann2019-12-171-1/+1
| | | | | | | document it This function is just setting the layout for the given RecordDecl so the current name is not very descriptive. Also add some documentation for it.
* [lldb] Add unit test for ClangASTImporterRaphael Isemann2019-12-162-0/+221
|
* [lldb] Centralize desugaring of decltype-like types in ClangASTContextPavel Labath2019-12-161-4/+36
| | | | | | | | | | | | | | | | | | | | | | Summary: These types were handled in some places, but not others. This resulted in (for example) not being able to display members of structs whose types were defined using these constructs. Using getLocallyUnqualifiedSingleStepDesugaredType for these types is not fully equivalent, as it will only desugar them if the types are not instantiation-dependent, whereas previously we did that unconditionally. It's not clear to me which behavior is correct here, but the test suite does not seem to care either way. Reviewers: teemperor, shafik Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71405
* [lldb][NFC] Fix file header of TestClangASTContext.cppRaphael Isemann2019-12-161-3/+1
|
* [lldb][NFC] Remove ClangASTContext::GetBuiltinTypeForEncodingAndBitSize overloadRaphael Isemann2019-11-291-19/+19
|
* [lldb][NFC] Simplify ClangASTContext::GetBasicTypesRaphael Isemann2019-11-201-2/+1
| | | | | static convenience methods that do the clang::ASTContext -> ClangASTContext conversion and handle errors by simply ignoring them are not a good idea.
* [lldb][NFC] Remove unused include in TestLineEntry.cppRaphael Isemann2019-09-201-1/+0
| | | | llvm-svn: 372381
* Fix windows build after r369894Pavel Labath2019-08-261-6/+4
| | | | | | | | | | | Constructing a std::vector from a llvm::map_range fails on windows, apparently because std::vector expects the input iterator to have a const operator* (map_range iterator has a non-const one). This avoids the cleverness and unrolls the map-loop manually (which is also slightly shorter). llvm-svn: 369905
* Postfix: move more code out of the PDB pluginPavel Labath2019-08-261-27/+56
| | | | | | | | | | | | | | | | Summary: Previously we moved the code which parses a single expression out of the PDB plugin, because that was useful for DWARF expressions in breakpad. However, FPO programs are used in breakpad files too (when unwinding on windows), so this completes the job, and moves the rest of the FPO parser too. Reviewers: amccarth, aleksandr.urakov Subscribers: aprantl, markmentovai, rnk, lldb-commits Differential Revision: https://reviews.llvm.org/D66634 llvm-svn: 369894
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-211-0/+44
| | | | | | | | | | | | | | | 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
* unittests: Use yaml2obj as a library instead of an external processPavel Labath2019-08-204-182/+161
| | | | | | | | | | | | | | | Summary: Recently, yaml2obj has been turned into a library. This means we can use it from our unit tests directly, instead of shelling out to an external process. This patch does just that. Reviewers: JDevlieghere, aadsm, espindola, jdoerfert Subscribers: emaste, mgorny, arichardson, MaskRay, jhenderson, abrachet, lldb-commits Differential Revision: https://reviews.llvm.org/D65949 llvm-svn: 369374
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-131-6/+8
| | | | | | | | | | 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
* SymbolVendor: Move Symtab construction into the SymbolFilePavel Labath2019-07-262-0/+4
| | | | | | | | | | | | | | | Summary: Instead of having SymbolVendor coordinate Symtab construction between Symbol and Object files, make the SymbolVendor function a passthrough, and put all of the logic into the SymbolFile. Reviewers: clayborg, JDevlieghere, jingham, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65208 llvm-svn: 367086
* Fixup r360161Pavel Labath2019-05-072-3/+1
| | | | | | | | | Remove SymbolVendorMacOSX from the test, as this plugin is not available on non-mac platforms, and it does not seem to be necessary anyway. Declare inlined-functions.yaml as an input of the test in cmake. llvm-svn: 360169
* PostfixExpression: Use signed integers in IntegerNodePavel Labath2019-05-071-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is necessary to support parsing expressions like ".cfa -16 + ^", as that format is used in breakpad STACK CFI expressions. Since the PDB expressions use the same parser, this change will affect them too, but I don't believe that should be a problem in practice. If PDBs do contain the negative values, it's very likely that they are intended to be parsed the same way, and if they don't, then it doesn't matter. In case that we do ever need to handle this differently, we can always make the parser behavior customizable, or just use a different parser. To make sure that the integer size is big enough for everyone, I switch from using a (unsigned) 32-bit integer to a 64-bit (signed) one. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D61311 llvm-svn: 360166
* Added missing files from 360071.Greg Clayton2019-05-073-0/+1179
| | | | llvm-svn: 360161
* [CMake] Remove lldbPluginSymbolVendorMacOSX to fix CMake buildJonas Devlieghere2019-05-061-1/+0
| | | | | | This should fix check-lldb-unit on the bots. llvm-svn: 360079
* [CMake] Remove inlined-functions.yamlJonas Devlieghere2019-05-061-1/+0
| | | | llvm-svn: 360078
* Fix the cmake build by removing non-existant source fileReid Kleckner2019-05-061-1/+0
| | | | llvm-svn: 360076
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-062-26/+9
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [C128] "Virtual functions should specify exactly one of `virtual`, `override`, or `final`", I've added override where a virtual function is overriden but the explicit `override` keyword was missing. Whenever both `virtual` and `override` were specified, I removed `virtual`. As C.128 puts it: > [...] writing more than one of these three is both redundant and > a potential source of errors. I anticipate a discussion about whether or not to add `override` to destructors but I went for it because of an example in [ISOCPP1000]. Let me repeat the comment for you here: Consider this code: ``` struct Base { virtual ~Base(){} }; struct SubClass : Base { ~SubClass() { std::cout << "It works!\n"; } }; int main() { std::unique_ptr<Base> ptr = std::make_unique<SubClass>(); } ``` If for some odd reason somebody removes the `virtual` keyword from the `Base` struct, the code will no longer print `It works!`. So adding `override` to destructors actively protects us from accidentally breaking our code at runtime. [C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final [ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555 Reviewers: teemperor, JDevlieghere, davide, shafik Reviewed By: teemperor Subscribers: kwk, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61440 llvm-svn: 359868
* PostfixExpression: Introduce InitialValueNodePavel Labath2019-04-301-0/+16
| | | | | | | | | | | | | | | | | | | | | | | Summary: This node represents can be used to refer to the initial value, which is sometimes pushed onto the DWARF stack as the "input" to the DWARF expression. The typical use case (and the reason why I'm introducing it) is that the "Canonical Frame Address" is passed this way to the DWARF expressions computing the values of registers during frame unwind. The nodes are converted into dwarf by keeping track of DWARF stack depth an any given point, and then copying the initial value from the bottom of the stack via the DW_OP_pick opcode. This could be made more efficient for simple expressions, but here I chose to start with the most general implementation possible. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai Differential Revision: https://reviews.llvm.org/D61183 llvm-svn: 359560
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-261-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new dwarf generator is pretty much a verbatim copy of the one in PDB. In order to write a pdb-independent test for it, I needed to write a dummy "symbol resolver", which (together with the fact that I'll need one more for breakpad-specific resolution logic) prompted me to create a more simple interface for algorithms which replace or "resolve" SymbolNodes. The resolving algorithms in NativePDB have been updated to make use of that too. I have removed a couple of NativePDB tests which weren't testing anything pdb-specific and where the tested functionality was covered by the new format-agnostic tests I have added. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D61056 llvm-svn: 359288
* PostfixExpression: move parser out of NativePDB internalsPavel Labath2019-04-242-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The postfix expressions in PDB and breakpad symbol files are similar enough that they can be parsed by the same parser. This patch generalizes the parser in the NativePDB plugin and moves it into the PostfixExpression file created in the previous commit (r358976). The generalization consists of treating any unrecognised token as a "symbol" node (previously these would only be created for tokens starting with "$", and other token would abort the parse). This is needed because breakpad symbols can also contain ".cfa" tokens, which refer to the frame's CFA. The cosmetic changes include: - using a factory function instead of a class for creating nodes (this is more generic as it allows the same BumpPtrAllocator to be used for other things too) - using dedicated function for parsing operator tokens instead of a DenseMap (more efficient as we don't need to create the DenseMap every time). Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny Differential Revision: https://reviews.llvm.org/D61003 llvm-svn: 359073
* [LLDB] - Update the test cases after yaml2obj change.George Rimar2019-04-031-16/+18
| | | | | | | | | https://reviews.llvm.org/D60122 (r357595) changed the symbols description format in yaml2obj. This change updates the LLDB tests. llvm-svn: 357600
* Resubmit "Don't include UnixSignals.h from Host."Zachary Turner2019-03-061-2/+7
| | | | | | | | This was reverted because it breaks the GreenDragon bot, but the reason for the breakage is lost, so I'm resubmitting this now so we can find out what the problem is. llvm-svn: 355528
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-272-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | 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
* TestClangASTContext: Rewrite an if-else chain into a switchPavel Labath2019-01-161-3/+11
| | | | | | | This avoids the "ambiguous else" warning, which comes from within the EXPECT_TRUE macro. llvm-svn: 351331
* Remove Go debugger pluginJonas Devlieghere2018-11-051-6/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Go debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54057 llvm-svn: 346157
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-1/+1
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [FileSystem] Extend file system and have it use the VFS.Jonas Devlieghere2018-10-312-7/+20
| | | | | | | | | | | | | | | | This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These methods will be removed in future commits and replaced by calls to the file system. The new functions are operated in terms of the virtual file system which was recently moved from clang into LLVM so it could be reused in lldb. Because the VFS is stateful, we turned the FileSystem class into a singleton. Differential revision: https://reviews.llvm.org/D53532 llvm-svn: 345783
* [NFC] Refactor SetBaseClasses and DeleteBaseClasses.Zachary Turner2018-10-251-11/+14
| | | | | | | | | | | | | | | | | | | | | | We currently had a 2-step process where we had to call SetBaseClassesForType and DeleteBaseClasses. Every single caller followed this exact 2-step process, and there was manual memory management going on with raw pointers. We can do better than this by storing a vector of unique_ptrs and passing this around. This makes for a cleaner API, and we only need to call one method so there is no possibility of a user forgetting to call DeleteBaseClassSpecifiers. In addition to this, it also makes for a *simpler* API. Part of why I wanted to do this is because when I was implementing the native PDB interface I had to spend some time understanding exactly what I was deleting and why. ClangAST has significant mental overhead associated with it, and reducing the API surface can go along way to making it simpler for people to understand. Differential Revision: https://reviews.llvm.org/D53590 llvm-svn: 345312
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-121-2/+3
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* [LLDB] Unit tests / typo fixDavid Carlier2018-06-071-1/+1
| | | | | | removing unnecessary comma. llvm-svn: 334177
* Remove spurious dependency on Process/elf-core from Process/Utility.James Y Knight2018-05-231-0/+1
| | | | | | | These checks do absolutely nothing other than cause a library layering violation in the code. llvm-svn: 333134
* Fix memory leak in TestClangASTContext.TestRecordHasFieldsRaphael Isemann2018-01-221-0/+5
| | | | | | | | | | Summary: We can't use unique_ptr's here because we use those variables as `out` parameters to some functions. Discovered by the memory sanitizer. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D42386 llvm-svn: 323138
* Fix assertion in ClangASTContextPavel Labath2017-11-301-7/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: llvm::APSInt(0) asserts because it creates an int with bit-width 0 and not (as I thought) a value 0. Theoretically it should be sufficient to change this to APSInt(1), as the intention there was that the value of the first argument should be ignored if the type is invalid, but that would look dodgy. Instead, I use llvm::Optional to denote an invalid value and use a special struct instead of a std::pair, to reduce typing and increase clarity. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D40615 llvm-svn: 319414
* CompilerType: Add ability to retrieve an integral template argumentPavel Labath2017-11-131-10/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: Despite it's name, GetTemplateArgument was only really working for Type template arguments. This adds the ability to retrieve integral arguments as well (which I've needed for the std::bitset data formatter). I've done this by splitting the function into three pieces. The idea is that one first calls GetTemplateArgumentKind (first function) to determine the what kind of a parameter this is. Based on that, one can then use specialized functions to retrieve the correct value. Currently, I only implement two of these: GetTypeTemplateArgument and GetIntegralTemplateArgument. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D39844 llvm-svn: 318040
OpenPOWER on IntegriCloud