[Lldb-commits] [lldb] [lldb] Make sure Blocks always have a parent (PR #117683)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Tue Nov 26 02:12:32 PST 2024


================
@@ -43,11 +43,13 @@ class Block : public UserID, public SymbolContextScope {
   typedef RangeVector<uint32_t, uint32_t, 1> RangeList;
   typedef RangeList::Entry Range;
 
-  /// Construct with a User ID \a uid, \a depth.
-  ///
-  /// Initialize this block with the specified UID \a uid. The \a depth in the
-  /// \a block_list is used to represent the parent, sibling, and child block
-  /// information and also allows for partial parsing at the block level.
+  // Creates a block representing the whole function. Only meant to be used from
+  // the Function class.
----------------
labath wrote:

I've thought about this for quite a while. I could befriend the whole class easily enough, but I think that would do more harm than good (it would give the Function class free reign over Block's innards. Befriending just the constructor is not possible because of it would cause a dependency loop between the classes, but even if it weren't, it would produce tighter coupling than I'd like (basically, you have to [match the constructor signature](https://godbolt.org/z/f95dnfjdh)). It is possible to befriend a class for construction without exposing all internals using the [tagged constructor pattern](https://godbolt.org/z/Ex367Wz68) -- I rejected that one because it seemed unnecessarily complicated.

I figured a constructor explicitly taking a Function pointer is going to be sufficiently un-useful, so it wouldn't be likely to be misused, but I could be easily convinced to do the constructor tag thingy.

https://github.com/llvm/llvm-project/pull/117683


More information about the lldb-commits mailing list