summaryrefslogtreecommitdiffstats
path: root/llvm/lib
diff options
context:
space:
mode:
authorGreg Clayton <gclayton@apple.com>2016-04-01 22:57:22 +0000
committerGreg Clayton <gclayton@apple.com>2016-04-01 22:57:22 +0000
commit58a15d5a235c57aafdc881250c25d8ce37a0f47e (patch)
tree0b077b7f3c06b2b9abad882ef6ccc777f9fc4d5c /llvm/lib
parent69c82bfae79426781e5a04b7ac450754dc33dc5d (diff)
downloadbcm5719-llvm-58a15d5a235c57aafdc881250c25d8ce37a0f47e.tar.gz
bcm5719-llvm-58a15d5a235c57aafdc881250c25d8ce37a0f47e.zip
Fixed an issue where if we have DWARF in an executable that has multiple languages where these languages use different type systems, you can end up trying to find the actualy definition for a forward declaration for a type, you will call:
TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx); The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty. This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations. <rdar://problem/25276165> llvm-svn: 265196
Diffstat (limited to 'llvm/lib')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud