[clang] [clang-tools-extra] [clang-tidy] `bugprone-unchecked-optional-access`: Improve handling of value constructors for `bsl::optional` and `bdlb::NullableValue` (PR #224969)

[Valentyn Yukhymenko via cfe-commits]

================
@@ -5,6 +5,32 @@
 
 namespace bsl {
   class string {};
+
+  template <typename T> class optional;
+
+  struct nullopt_t {
+    constexpr explicit nullopt_t() {}
+  };
+
+  constexpr nullopt_t nullopt;
+
+  struct in_place_t {
+    constexpr explicit in_place_t() {}
+  };
+
+  constexpr in_place_t in_place;
+
+  struct allocator_arg_t {
+    constexpr explicit allocator_arg_t() {}
+  };
+
+  constexpr allocator_arg_t allocator_arg;
+
+  /// Mock of the allocator type taken by the allocator-extended constructors.
+  class allocator {};
+
+  template <bool B, class T> struct enable_if {};
----------------
BaLiKfromUA wrote:

Short answer -- I don't know since I am not from BDE team :D

_My understanding of it:_

If you are asking exactly about `bsl::enable_if` -- I would expect once min supported C++ version becomes 11+ then it could become an alias. But as of now, [BDE supports C++ 03](https://bloomberg.github.io/bde/library_information/supported_platforms.html#tiers-of-support).

If you are asking about `bsl::optional` then I am not as sure since `bsl::optional` is allocator-aware and BDE uses `std::optional` under the hood only when type inside doesn't need allocator awareness.

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