[all-commits] [llvm/llvm-project] 51d8c5: [lldb] Don't model std::atomic as a transparent da...

Raphael Isemann via All-commits all-commits at lists.llvm.org
Tue Feb 18 02:22:32 PST 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 51d8c598331b25568b38691575c39729ae81a059
      https://github.com/llvm/llvm-project/commit/51d8c598331b25568b38691575c39729ae81a059
  Author: Raphael Isemann <teemperor at gmail.com>
  Date:   2020-02-18 (Tue, 18 Feb 2020)

  Changed paths:
    M lldb/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp
    M lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
    M lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/main.cpp

  Log Message:
  -----------
  [lldb] Don't model std::atomic as a transparent data structure in the data formatter

Summary:
Currently the data formatter is treating `std::atomic` variables as transparent wrappers
around their underlying value type. This causes that when printing `std::atomic<A *>`, the data
formatter will forward all requests for the children of the atomic variable to the `A *` pointer type
which will then return the respective members of `A`. If `A` in turn has a member that contains
the original atomic variable, this causes LLDB to infinitely recurse when printing an object with
such a `std::atomic` pointer member.

We could implement a workaround similar to whatever we do for pointer values but this patch
just implements the `std::atomic` formatter in the same way as we already implement other
formatters (e.g. smart pointers or `std::optional`) that just model the contents of the  as a child
"Value". This way LLDB knows when it actually prints a pointer and can just use its normal
workaround if "Value" is a recursive pointer.

Fixes rdar://59189235

Reviewers: JDevlieghere, jingham, shafik

Reviewed By: shafik

Subscribers: shafik, christof, jfb, abidh, lldb-commits

Tags: #lldb

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




More information about the All-commits mailing list