[all-commits] [llvm/llvm-project] 4db54e: [clang][DebugInfo] Revert "emit definitions for co...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4db54e659763401dbf2e5b1f90e9a3391e311e50
      https://github.com/llvm/llvm-project/commit/4db54e659763401dbf2e5b1f90e9a3391e311e50
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2023-12-06 (Wed, 06 Dec 2023)

  Changed paths:
    M clang/lib/CodeGen/CGDebugInfo.cpp
    M clang/lib/CodeGen/CGDebugInfo.h
    M clang/test/CodeGenCXX/debug-info-class.cpp
    R clang/test/CodeGenCXX/debug-info-static-inline-member.cpp
    M clang/test/CodeGenCXX/debug-info-static-member.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
    M lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py

  Log Message:
  -----------
  [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (#74580)

This commit reverts the changes in
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up
patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC emits definitions for static data member constants into the Names
index, they do so *only* for explicitly `constexpr` members. We were
indexing *all* constant-initialized const-static members, which is
likely where the significant size difference comes from. However, only
emitting explicitly `constexpr` variables into the index doesn't seem
like a good way forward, since from clang's perspective `const`-static
integrals are `constexpr` too, and that shouldn't be any different in
the debug-info component. Also, as new code moves to `constexpr` instead
of `const` static for constants, such solution would just delay the
growth of the Names index.

To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.

To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.