summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/NativePDB
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Create type-safe function for creating a CompilerType from a ↵Raphael Isemann2020-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | QualType LLDB frequently converts QualType to CompilerType. This is currently done like this: result = CompilerType(this, qual_type_var.getAsOpaquePtr()) There are a few shortcomings in this current approach: 1. CompilerType's constructor takes a void* pointer so it isn't type safe. 2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type actually belongs to the passed ClangASTContext) without expanding the TypeSystem API. 3. The logic for converting QualType->CompilerType is spread out over all of LLDB so changing it is difficult (e.g., what if we want to just pass the type ptr and not the 1type_ptr | qual_flags1 to CompilerType). This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl functions that does this conversion in a type safe way. It also adds a sanity check for Tag-based types that the type actually belongs to the current ClangASTContext (Types don't seem to know their ASTContext, so we have to workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types we construct but it's better than no sanity check).
* [lldb][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-231-1/+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-211-8/+6
| | | | | | | | | | | 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] Use StringRef in CreateRecordType and CreateObjCClassRaphael Isemann2019-12-171-3/+2
|
* [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][NFC] Remove all unnecessary includes for ClangASTSourceCommon.hRaphael Isemann2019-12-172-2/+1
| | | | | These files only need the definition of ClangASTMetadata (which was previously in the ClangASTSourceCommon.h) or don't need the include at all.
* [lldb] Don't put compile unit name into the support file list and support ↵Pavel Labath2019-12-051-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
* Replace bitfield in lldb::Type with byte-sized members. (NFC)Adrian Prantl2019-11-181-11/+11
| | | | | | Due to alginment and packing using separate members takes up the same amount of space, but makes it far less cumbersome to deal with it in constructors etc.
* Add RTTI support to the SymbolFile class hierarchyAdrian Prantl2019-11-152-0/+13
| | | | Differential Revision: https://reviews.llvm.org/D70322
* Performance: Add a set of visited SymbolFiles to the other FindFiles variant.Adrian Prantl2019-11-122-2/+4
| | | | | | | | | | | | | | This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-172-23/+17
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* [NativePDB] Remove unused references to ClangASTImporterAlex Langford2019-10-112-3/+0
| | | | llvm-svn: 374587
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-041-2/+3
| | | | | | | | | Link against clang-cpp dylib rather than split libs when CLANG_LINK_CLANG_DYLIB is enabled. Differential Revision: https://reviews.llvm.org/D68456 llvm-svn: 373734
* Remove size_t return parameter from FindTypesAdrian Prantl2019-10-012-33/+23
| | | | | | | | | | | | | | | In r368345 I accidentally introduced a regression that would over-report the number of matches found by FindTypes if the DeclContext Filter was hit. This patch simply removes the size_t return parameter altogether — it's not that useful. rdar://problem/55500457 Differential Revision: https://reviews.llvm.org/D68169 llvm-svn: 373344
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-302-9/+4
| | | | | | | | | | | | | I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it incorrectly (passing append=false in a for-loop to recursive calls to FindTypes would yield only the very last set of results), but instead of fixing it, removing it seemed like an even better option. rdar://problem/54412692 Differential Revision: https://reviews.llvm.org/D68171 llvm-svn: 373224
* DWARFExpression: Simplify class interfacePavel Labath2019-08-271-2/+2
| | | | | | | | | | | | | | | | | Summary: The DWARFExpression methods have a lot of arguments. This removes two of them by removing the ability to slice the expression via two offset+size parameters. This is a functionality that it is not always needed, and when it is, we already have a different handy way of slicing a data extractor which we can use instead. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66745 llvm-svn: 370027
* Postfix: move more code out of the PDB pluginPavel Labath2019-08-261-47/+13
| | | | | | | | | | | | | | | | 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
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-222-3/+6
| | | | | | | | | | | | | | | | | | | 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-222-6/+3
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-222-3/+6
| | | | | | | | | | | | | | | | | 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
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-212-4/+3
| | | | | | | | | | | | | | | 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
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-142-6/+6
| | | | | | | | | | 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
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367850
* Fix ClangASTContext::CreateParameterDeclaration to not call addDeclShafik Yaghmour2019-08-021-1/+1
| | | | | | | | | Summary: The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang. Differential Revision: https://reviews.llvm.org/D65414 llvm-svn: 367726
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
* SymbolVendor: Remove the object file member variablePavel Labath2019-07-312-14/+14
| | | | | | | | | | | | | | | | | | Summary: The last responsibility of the SymbolVendor was to hold an owning reference to the object file (in case symbols are being read from a different file than the main module). As SymbolFile classes already hold a non-owning reference to the object file, we can easily remove this responsibility of the SymbolVendor by making the SymbolFile reference owning. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65401 llvm-svn: 367392
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-304-21/+22
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* SymbolVendor: Move locking into the Symbol FilesPavel Labath2019-07-301-0/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: The last bit of functionality in SymbolVendor passthrough functions is the locking the module mutex. While it may be nice doing the locking in a central place, we weren't really succesful in doing that right now, because some SymbolFile function could still be called without going through the SymbolVendor. This meant in SymbolFileDWARF (the only battle-tested symbol file implementation) roughly a half of the functions was taking additional locks and another half was asserting that the lock is already held. By making the SymbolFile responsible for locking, we can at least make the situation in SymbolFileDWARF more consistent. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D65329 llvm-svn: 367298
* SymbolVendor: Remove the type list memberPavel Labath2019-07-251-3/+3
| | | | | | | | | | | | | | | | | | | | | Summary: Similarly to the compile unit lists, the list of types can also be managed by the symbol file itself. Since the only purpose of this list seems to be to maintain an owning reference to all the types a symbol file has created (items are only ever added to the list, never retrieved), I remove the passthrough functions in SymbolVendor and Module. I also tighten the interface of the function (return a reference instead of a pointer, make it protected instead of public). Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65135 llvm-svn: 366994
* SymbolVendor: Move compile unit handling into the SymbolFile classPavel Labath2019-07-232-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFile classes are responsible for creating CompileUnit instances and they already need to have a notion of the id<->CompileUnit mapping (because of APIs like ParseCompileUnitAtIndex). However, the SymbolVendor has remained as the thing responsible for caching created units (which the SymbolFiles were calling via convoluted constructs like "m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)"). This patch moves the responsibility of caching the units into the SymbolFile class. It does this by moving the implementation of SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the equivalent SymbolFile functions. The SymbolVendor functions become just a passthrough much like the rest of SymbolVendor. The original implementations of SymbolFile::GetNumCompileUnits is moved to "CalculateNumCompileUnits", and are made protected, as the "Get" function is the external api of the class. SymbolFile::ParseCompileUnitAtIndex is made protected for the same reason. This is the first step in removing the SymbolVendor indirection, as proposed in <http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After removing all interesting logic from the SymbolVendor class, I'll proceed with removing the indirection itself. Reviewers: clayborg, jingham, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65089 llvm-svn: 366791
* [NativePDB] Make GetOrCreateDeclForUid return an lldb CompilerDeclNathan Lanza2019-07-213-12/+16
| | | | | | | | | We intend to make PdbAstBuilder abstract and implement PdbAstBuilderClang along with any other languages that wish to use PDBs. Thus, change GetOrCreateDeclForUid from returning a clang decl to a lldb_private::CompilerDecl. llvm-svn: 366650
* [NativePDB] Add a FromCompilerDecl for going from lldb -> clangNathan Lanza2019-07-172-0/+5
| | | | | | | | | | Summary: A common transformation in NativePDB is to go from lldb types to clang types and vice versa. This function automates one of those steps. Differential Revision: https://reviews.llvm.org/D64851 llvm-svn: 366345
* [NativePDB] Make GetTranslationUnitDecl return an lldb CompilerDeclCtxNathan Lanza2019-07-172-10/+11
| | | | | | | | | | | Summary: We intend to make PdbAstBuilder abstract and implement PdbAstBuilderClang along with any other languages that wish to use PDBs. This is the first step. Differential Revision: https://reviews.llvm.org/D64852 llvm-svn: 366293
* [COFF, ARM64] Fix CodeView API change for getRegisterNamesTom Tan2019-06-031-1/+12
| | | | | | | | | Change rL362280 changed CodeView API getRegisterNames() by adding an input parameter in CPUType. It is called in LLDB and needs to be updated. Differential Revision: https://reviews.llvm.org/D62772 llvm-svn: 362349
* [DWARFExpression] Remove ctor that takes just a compile unit.Jonas Devlieghere2019-05-281-2/+2
| | | | | | | | | | | | | | | | Like many of our DWARF classes, the DWARFExpression can be initialized in several ways. One such way was through a constructor that takes just the compile unit. This constructor is used to initialize both empty DWARFExpressions, and DWARFExpression that will be populated later. To make the distinction more clear, I changed the constructor to a default constructor and updated its call sites. Where the DWARFExpression was being populated later, I replaced that with a call to the copy assignment constructor. Differential revision: https://reviews.llvm.org/D62425 llvm-svn: 361849
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-132-0/+19
| | | | | | | | | | | | | | | | | Summary: This patch implements missing case in PdbAstBuilder::CreateType for LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct methods. Reviewers: amccarth, aleksandr.urakov Reviewed By: amccarth Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy Differential Revision: https://reviews.llvm.org/D61128 llvm-svn: 360569
* Fix file names in file headers. NFCFangrui Song2019-05-133-3/+3
| | | | llvm-svn: 360554
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-261-183/+16
| | | | | | | | | | | | | | | | | | | | | | | | | 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-241-96/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move postfix expression code out of the NativePDB pluginPavel Labath2019-04-231-233/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The NativePDB plugin contains code to convert "programs" describing the layout of function frames into dwarf (for easier interaction with the rest of lldb). This functionality is useful for the Breakpad plugin too, as it contains the same kind of expressions (because breakpad info is generated from pdb files). In this patch, I move the core classes of this code into a common place, where it can be used from both files. Previously, these were the details of the implementation, but here I am exposing them (instead of just a single "string->string" conversion function), as breakpad will need to use these in a slightly different way. The reason for that is that breakpad files generated from dwarf expressions use a slightly different syntax, although most of the core code can be reused with a bit of thought. This is also the reason why I am not moving the parsing or dwarf generation bits, as they will need to be generalized a bit before they're usable for both scenarios. This patch should be NFC, modulo renaming the moved entities to more neutral names. The reason I am moving this to the "Symbol" library, is because both customers will be "Symbol"Files, and also the unwinding code lives in the Symbol library. From a purely dependency standpoint this code will probably be standalone, and so it could be moved all the way to Utility, but that seems too low for this kind of functionality. Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D60599 llvm-svn: 358976
* [NativePDB] Add anonymous namespaces supportAleksandr Urakov2019-04-222-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds anonymous namespaces support to the native PDB plugin. I had to reference from the main function variables of the types that are inside of the anonymous namespace to include them in debug info. Without the references they are not included. I think it's because they are static, then are visible only in the current translation unit, so they are not needed without any references to them. There is also the problem case with variables of types that are nested in template structs. For now I've left FIXME in the test because this case is not related to the change. Reviewers: zturner, asmith, labath, stella.stamenova, amccarth Reviewed By: amccarth Subscribers: zloyrobot, aprantl, teemperor, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D60817 llvm-svn: 358873
* Fix compiler warning introduced by r358261Pavel Labath2019-04-121-0/+2
| | | | | | Add a virtual destructor to the class with virtual methods. llvm-svn: 358284
* PDBFPO: Improvements to the AST visitorPavel Labath2019-04-121-138/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch attempts to solve two issues made this code hard to follow for me. The first issue was that a lot of what these visitors do is mutate the AST. The visitor pattern is not particularly good for that because by the time you have performed the dynamic type dispatch, it's too late to go back to the parent node, and change its pointer. The previous code dealt with that relatively elegantly, but it still meant that one had to perform manual type checks, which is what the visitor pattern is supposed to avoid. The second issue was not being able to return values from the Visit functions, which meant that one had to store function results in member variables (a common problem with visitor patterns). Here, I solve both problems by making the visitor use a type switch instead of going through double dispatch on the visited object. This allows one to parameterize the visitor based on the return type and pass function results as function results. The mutation is fascilitated by having each Visit function take two arguments -- a reference to the object itself (with the correct dynamic type), and a reference to the parent's pointer to this object. Although this wasn't my explicit goal here, the fact that we're not using virtual dispatch anymore allows us to make the AST nodes trivially destructible, which is a good thing, since we were not destroying them anyway. Reviewers: aleksandr.urakov, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60410 llvm-svn: 358261
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-102-8/+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
* PDBFPO: add dyn_cast supportPavel Labath2019-04-081-7/+25
| | | | | | | This adds the necessary glue so we can use llvm::dyn_cast, instead of doing a manual type-check followed by a cast. NFC. llvm-svn: 357895
* PDBFPO: Use references instead of pointers, where possiblePavel Labath2019-04-051-65/+63
| | | | | | | | | | | | | | | | | | | Summary: The code was passing pointers around, expecting they would be not null. In c++ it is possible to convey this notion explicitly by using a reference instead. Not all uses of pointers could be converted to references (e.g. one can't store references in a container), but this will at least make it locally obvious that code is dealing with nonnull pointers. Reviewers: aleksandr.urakov, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60271 llvm-svn: 357744
* [codeview] Remove Type member from CVRecordReid Kleckner2019-04-041-1/+1
| | | | | | | | | | | | | | | | | Summary: Now CVType and CVSymbol are effectively type-safe wrappers around ArrayRef<uint8_t>. Make the kind() accessor load it from the RecordPrefix, which is the same for types and symbols. Reviewers: zturner, aganea Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60018 llvm-svn: 357658
* [NativePDB] Don't fail on import modules.Zachary Turner2019-04-021-2/+11
| | | | | | | | | | | A recent patch to LLD started emitting information about import modules. These are represented as compile units in the PDB, but with no additional debug info. This was confusing the native pdb reader, who expected that the debug info stream be present. This should fix failing tests on the Windows bots. llvm-svn: 357513
OpenPOWER on IntegriCloud