summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/PDB
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Remove some calls to GetASTContextRaphael Isemann2019-12-261-14/+7
| | | | | | | GetASTContext is really expensive to call as it makes use of the global mapping from ASTContext to ClangASTContext. This replaces all calls where we already have the ClangASTContext around and don't need to call GetASTContext again.
* [lldb][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-232-5/+4
| | | | | | | | | | | | | | | 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-25/+23
| | | | | | | | | | | 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/+3
|
* [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-171-1/+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-7/+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
* [lldb] Remove FileSpec->CompileUnit inheritancePavel Labath2019-11-291-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
* Replace bitfield in lldb::Type with byte-sized members. (NFC)Adrian Prantl2019-11-181-12/+12
| | | | | | 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-3/+5
| | | | | | | | | | | | | | 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
* (NFC) Delete variable made unused by llvm-svn: 375160Sterling Augustine2019-10-171-1/+0
| | | | | | | | | | | | Reviewers: aprantl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69143 llvm-svn: 375174
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-172-49/+33
| | | | | | | | | | | | 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
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-091-1/+0
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-041-3/+4
| | | | | | | | | 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
* [lldb] Fix unused variable warningJordan Rupprecht2019-10-011-1/+0
| | | | llvm-svn: 373399
* Update SymbolFilePDB for FindTypes API change.Adrian Prantl2019-10-012-22/+17
| | | | | | This is untested, I don't have access to a Windows machine. llvm-svn: 373342
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-302-8/+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-1/+1
| | | | | | | | | | | | | | | | | 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
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-222-2/+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/+2
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-222-2/+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-141-1/+1
| | | | | | | | | | 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
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-131-7/+14
| | | | | | | | | | 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
* 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
* SymbolVendor: Remove the object file member variablePavel Labath2019-07-312-15/+16
| | | | | | | | | | | | | | | | | | 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
* Change '|' to '&' in conditional.Richard Trieu2019-07-311-1/+1
| | | | | | | | Bitwise-or with a non-zero constant will always evaluate to true. Switch to bitwise-and which will only evalute to true if the specified bit is set in the other operand. llvm-svn: 367386
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-302-32/+118
| | | | | | | | | | | | | | | | | | 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/+17
| | | | | | | | | | | | | | | | | | | | | | 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-252-9/+1
| | | | | | | | | | | | | | | | | | | | | 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-35/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [DWARFExpression] Remove ctor that takes just a compile unit.Jonas Devlieghere2019-05-281-7/+7
| | | | | | | | | | | | | | | | 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
* [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
* Kill unused variable m_tu_decl_up in SymbolFilePDBNathan Lanza2019-03-272-10/+1
| | | | | | | | | | | | | | | | | | Summary: An TranslationUnitDecl was being brought in from the clang::ASTContext which required clang specific code to exist in SymbolFilePDB. Since it was unused we can just get rid of it along with the clang specific code. Reviewers: rnk, zturner, compnerd Reviewed By: compnerd Subscribers: jdoerfert Differential Revision: https://reviews.llvm.org/D59804 llvm-svn: 357113
* Get the lang from the CompileUnit for ParseCompileUnitFunctionForPDBFuncNathan Lanza2019-03-271-1/+2
| | | | | | | | | | | | Summary: Instead of assuming that the language is C++ instead check the compunit for the language it received from the debug info. Subscribers: aprantl, jdoerfert Differential Revision: https://reviews.llvm.org/D59805 llvm-svn: 357044
* Add a case in SymbolFile{Native,}PDB::TranslateLanguage for SwiftNathan Lanza2019-03-111-0/+2
| | | | | | | | | | Summary: see above Reviewers: compnerd Differential Revision: https://reviews.llvm.org/D59230 llvm-svn: 355883
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-111-5/+5
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Pass ConstString by value (NFC)Adrian Prantl2019-03-062-8/+8
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-181-1/+1
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Deserialize Clang module search path from DWARFAdrian Prantl2019-02-132-2/+2
| | | | | | | | | | | | This patch properly extracts the full submodule path as well as its search paths from DWARF import decls and passes it on to the ClangModulesDeclVendor. rdar://problem/47970144 Differential Revision: https://reviews.llvm.org/D58090 llvm-svn: 353961
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-132-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-014-473/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | stored relative to VFRAME Summary: This patch makes LLDB able to retrieve proper values for function arguments and local variables stored in PDB relative to VFRAME register. Patch contains retrieval of corresponding FPO table entries from PDB and a generic translator from FPO programs to DWARF expressions to get correct VFRAME value. Patch also improves variables-locations.test and makes this test passable on x86. Patch By: leonid.mashinsky Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov Reviewed By: zturner Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D55122 llvm-svn: 352845
* Make a blind attempt at fixing PDBASTParser nullability issuesAdrian Prantl2019-01-291-2/+6
| | | | llvm-svn: 352548
* Make Type::GetByteSize optional (NFC)Adrian Prantl2019-01-291-6/+10
| | | | | | | | | | | This is a continuation of my quest to make the size 0 a supported value. This reapplies r352394 with additional PDB parser fixes prepared by Pavel Labath! Differential Revision: https://reviews.llvm.org/D57273 llvm-svn: 352521
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-196-24/+18
| | | | | | | | | | | | | | | | | 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-142-3/+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
* [SymbolFile] Remove the SymbolContext parameter from FindNamespace.Zachary Turner2019-01-142-2/+0
| | | | | | | | | | | Every callsite was passing an empty SymbolContext, so this parameter had no effect. Inside the DWARF implementation of this function, however, there was one codepath that checked members of the SymbolContext. Since no call-sites actually ever used this functionality, it was essentially dead code, so I've deleted this code path as well. llvm-svn: 351132
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-142-13/+9
| | | | | | | | | | | | | This method took a SymbolContext but only actually cared about the case where the m_function member was set. Furthermore, it was intended to be implemented to parse blocks recursively despite not documenting this in its name. So we change the name to indicate that it should be recursive, while also limiting the function parameter to be a Function&. This lets the caller know what is required to use it, as well as letting new implementers know what kind of inputs they need to be prepared to handle. llvm-svn: 351131
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-112-65/+45
| | | | | | | | | | | | | | | | Previously all of these functions accepted a SymbolContext&. While a CompileUnit is one member of a SymbolContext, there are also many others, and by passing such a monolithic parameter in this way it makes the requirements and assumptions of the API unclear for both callers as well as implementors. All these methods need is a CompileUnit. By limiting the parameter type in this way, we simplify the code as well as make it self-documenting for both implementers and users. Differential Revision: https://reviews.llvm.org/D56564 llvm-svn: 350943
OpenPOWER on IntegriCloud