In some cases, type lookup has to deal with situations where it cannot reconstruct a compile unit or a function, but it still has a valid symbol - and it can use that in order to figure out the preferential language for lookups

This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code

Fixes rdar://problem/22422313

llvm-svn: 269095
This commit is contained in:
Enrico Granata 2016-05-10 18:16:33 +00:00
parent ccdc225c27
commit c3b0a5b099
1 changed files with 23 additions and 1 deletions

View File

@ -34,6 +34,7 @@
#include "lldb/Interpreter/OptionValueBoolean.h"
#include "lldb/Interpreter/OptionValueLanguage.h"
#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Symbol/Symbol.h"
#include "lldb/Target/Language.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/StackFrame.h"
@ -3209,6 +3210,27 @@ CommandObjectTypeFilterAdd::CommandOptions::g_option_table[] =
class CommandObjectTypeLookup : public CommandObjectRaw
{
protected:
// this function is allowed to do a more aggressive job at guessing languages than the expression parser
// is comfortable with - so leave the original call alone and add one that is specific to type lookup
lldb::LanguageType
GuessLanguage (StackFrame *frame)
{
lldb::LanguageType lang_type = lldb::eLanguageTypeUnknown;
if (!frame)
return lang_type;
lang_type = frame->GuessLanguage();
if (lang_type != lldb::eLanguageTypeUnknown)
return lang_type;
Symbol *s = frame->GetSymbolContext(eSymbolContextSymbol).symbol;
if (s)
lang_type = s->GetMangled().GuessLanguage();
return lang_type;
}
class CommandOptions : public OptionGroup
{
public:
@ -3403,7 +3425,7 @@ public:
// so the cost of the sort is going to be dwarfed by the actual lookup anyway
if (StackFrame* frame = m_exe_ctx.GetFramePtr())
{
LanguageType lang = frame->GuessLanguage();
LanguageType lang = GuessLanguage(frame);
if (lang != eLanguageTypeUnknown)
{
std::sort(languages.begin(),