[all-commits] [llvm/llvm-project] cd2134: [lldb] Refactor Module::LookupInfo constructor

[Alex via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cd2134e42aa7d1168a3ed54e41793b022f961b1f
      https://github.com/llvm/llvm-project/commit/cd2134e42aa7d1168a3ed54e41793b022f961b1f
  Author: Alex Langford <apl at fb.com>
  Date:   2021-08-24 (Tue, 24 Aug 2021)

  Changed paths:
    M lldb/include/lldb/Core/Module.h
    M lldb/include/lldb/Target/Language.h
    M lldb/source/Core/CMakeLists.txt
    M lldb/source/Core/Module.cpp
    M lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
    M lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
    M lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
    M lldb/source/Plugins/Language/ObjC/ObjCLanguage.h

  Log Message:
  -----------
  [lldb] Refactor Module::LookupInfo constructor

Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like a great candidate for refactoring. Specifically, this is work
that can be delegated to language plugins.

Once again, the goal here is to further decouple plugins from
non-plugins. The idea is to have each language plugin take a name and
give you back some information about the name from the perspective of
the language. Specifically, each language now implements a
`GetFunctionNameInfo` method which returns an object of type
`Language::FunctionNameInfo`. Right now, it consists of a basename,
a context, and a FunctionNameType. Module::LookupInfo's constructor will
call `GetFunctionNameInfo` with the appropriate language plugin(s) and
then decide what to do with that information. I have attempted to maintain
existing behavior as best as possible.

A nice side effect of this change is that lldbCore no longer links
against the ObjC Language plugin.

Differential Revision: https://reviews.llvm.org/D108229