[Lldb-commits] [lldb] [lldb] Realpath symlinks for breakpoints (PR #102223)

[via lldb-commits]

================
@@ -0,0 +1,66 @@
+//===-- RealpathPrefixes.cpp ----------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "lldb/Utility/RealpathPrefixes.h"
+
+#include "lldb/Target/Statistics.h"
+#include "lldb/Target/Target.h"
----------------
royitaqi wrote:

> If you want this to be a Utility class
What is the general guidance of when a class should be in "Target" vs. in "Utility"?

> dependency inversion technique
Like how?

I tried to make an interface `RealpathPrefixStats` which contains the two increment functions, then have `TargetStats` implement this interface, in the hope of the Target can create the `RealpathPrefix` and feed its own `TargetStats` to it as `RealpathPrefixStats` (where `RealpathPrefixStats` only sees `RealpathPrefixStats`, which is also in `Utility`).

However, there is the lifecycle problem Jim pointed out earlier, that what guarantees that the `RealpathPrefixStats` object lives longer than the `RealpathPrefix` object. In order to guarantee this, I will need to make `Target::m_stats` a shared pointer, then give a weak pointer of `RealpathPrefixStats` to `RealpathPrefix`.

Is the above a good plan? Do you see a better approach?


---

FWIW, I did search for the inclusion of Target stuff in Utility, but did it wrong and thought it's a common case. This involves a VS Code bug in "Find in Folder...".

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