[all-commits] [llvm/llvm-project] fe8e25: [lldb][NFC] Create type-safe function for creating...

Raphael Isemann via All-commits all-commits at lists.llvm.org
Thu Jan 2 02:55:02 PST 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: fe8e25a48a2a0f8f508499ba950181dba3d600b0
      https://github.com/llvm/llvm-project/commit/fe8e25a48a2a0f8f508499ba950181dba3d600b0
  Author: Raphael Isemann <teemperor at gmail.com>
  Date:   2020-01-02 (Thu, 02 Jan 2020)

  Changed paths:
    M lldb/include/lldb/Symbol/ClangASTContext.h
    M lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
    M lldb/source/Plugins/Language/ObjC/NSArray.cpp
    M lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
    M lldb/source/Symbol/ClangASTContext.cpp

  Log Message:
  -----------
  [lldb][NFC] Create type-safe function for creating a CompilerType from a 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).




More information about the All-commits mailing list