[all-commits] [llvm/llvm-project] ca64f9: [lldb][DWARFASTParserClang][NFC] Simplify unnamed ...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ca64f9af04472a27656d84c06f4e332ebbf14b4d
      https://github.com/llvm/llvm-project/commit/ca64f9af04472a27656d84c06f4e332ebbf14b4d
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

  Log Message:
  -----------
  [lldb][DWARFASTParserClang][NFC] Simplify unnamed bitfield condition

Minor cleanup of redundant variable initialization and
if-condition. These are leftovers/oversights from previous
cleanup in this area:
* https://reviews.llvm.org/D72953
* https://reviews.llvm.org/D76808

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


  Commit: 56eff197d0d629c768e8e48fb995e8a1d2cd6441
      https://github.com/llvm/llvm-project/commit/56eff197d0d629c768e8e48fb995e8a1d2cd6441
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h

  Log Message:
  -----------
  [lldb][DWARFASTParserClang][NFC] Extract condition for unnamed bitfield creation into helper function

This patch adds a new private helper
`DWARFASTParserClang::ShouldCreateUnnamedBitfield` which
`ParseSingleMember` whether we should fill the current gap
in a structure layout with unnamed bitfields.

Extracting this logic will allow us to add additional
conditions in upcoming patches without jeoperdizing readability
of `ParseSingleMember`.

We also store some of the boolean conditions in local variables
to make the intent more obvious.

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


  Commit: 3c30f224005e3749c89e00592bd2a43aba2aaf75
      https://github.com/llvm/llvm-project/commit/3c30f224005e3749c89e00592bd2a43aba2aaf75
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
    M lldb/test/API/lang/cpp/bitfields/TestCppBitfields.py
    M lldb/test/API/lang/cpp/bitfields/main.cpp

  Log Message:
  -----------
  [lldb][DWARFASTParserClang] Don't create unnamed bitfields to account for vtable pointer

**Summary**

When filling out the LayoutInfo for a structure with the offsets
from DWARF, LLDB fills gaps in the layout by creating unnamed
bitfields and adding them to the AST. If we don't do this correctly
and our layout has overlapping fields, we will hat an assertion
in `clang::CGRecordLowering::lower()`. Specifically, if we have
a derived class with a VTable and a bitfield immediately following
the vtable pointer, we create a layout with overlapping fields.

This is an oversight in some of the previous cleanups done around this
area.

In `D76808`, we prevented LLDB from creating unnamed bitfields if there
was a gap between the last field of a base class and the start of a bitfield
in the derived class.

In `D112697`, we started accounting for the vtable pointer. The intention
there was to make sure the offset bookkeeping accounted for the
existence of a vtable pointer (but we didn't actually want to create
any AST nodes for it). Now that `last_field_info.bit_size` was being
set even for artifical fields, the previous fix `D76808` broke
specifically for cases where the bitfield was the first member of a
derived class with a vtable (this scenario wasn't tested so we didn't
notice it). I.e., we started creating redundant unnamed bitfields for
where the vtable pointer usually sits. This confused the lowering logic
in clang.

This patch adds a condition to `ShouldCreateUnnamedBitfield` which
checks whether the first field in the derived class is a vtable ptr.

**Testing**

* Added API test case

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


Compare: https://github.com/llvm/llvm-project/compare/c2d55ef563a9...3c30f224005e