[Lldb-commits] [lldb] [lldb] Eliminate SupportFileSP nullptr derefs (PR #168624)

[Augusto Noronha via lldb-commits]

================
@@ -0,0 +1,84 @@
+//===----------------------------------------------------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLDB_UTILITY_NONNULLSHAREDPTR_H
+#define LLDB_UTILITY_NONNULLSHAREDPTR_H
+
+#include <memory>
+#include <utility>
+
+namespace lldb_private {
+
+/// A non-nullable shared pointer that always holds a valid object.
+///
+/// NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that
+/// guarantees the pointer is never null. If default-constructed, it creates
+/// a default-constructed instance of T.
+///
+/// This class is used for enforcing invariants at the type level and
+/// eliminating entire classes of null pointer bugs.
+///
+/// @tparam T The type of object to manage. Must be default-constructible.
+template <typename T> class NonNullSharedPtr : private std::shared_ptr<T> {
+  using Base = std::shared_ptr<T>;
+
+public:
+  NonNullSharedPtr() : Base(std::make_shared<T>()) {}
----------------
augusto2112 wrote:

Is default construction something we really need to support SupportFileSP?

In my opinion it would be better if users of this type explicitly initialize an empty object if they want to, since default constructed values, while not as bad as nullptrs, might still lead to code with logic errors, where the container is accidentally left uninitialized.

At the same time I know there are a lot of default constructed objects in LLDB, so it might not be worth changing this.

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