[clang] [clang-tools-extra] [clang-tidy] `bugprone-unchecked-optional-access`: handle `BloombergLP::bdlb:NullableValue::makeValue` to prevent false-positives (PR #144313)
Artem Dergachev via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 1 15:57:44 PDT 2025
haoNoQ wrote:
> > At the moment of the previous PR, there was a concern about configurability of check
>
> I think I was about adding an option to configure list of optional classes. Probably `OptionalClasses` or similar. I haven't seen issues about it, so it may not be a high priority.
All warnings/checks focused on misuse of specific standard C++ classes have to deal with that same problem at some point. If only there was a universal, reusable solution in Clang! Like, it'd be nice if there was some kind of fancy attribute to annotate classes as "similar" to standard classes:
```c++
[[clang::this_class_is_basically_a_custom("std::optional")]]
class NullableValue {
public:
[[clang::this_method_basically_works_like("std::optional::emplace")]]
template <typename... T> T &makeValueInplace(T &&... args);
};
```
An attribute-based solution would be particularly useful when you're shipping a library and you get to add the attributes to your headers. This way you don't have to ask your users to include stuff in their respective clang-tidy configs whenever they include your library. It'd simply work "out of the box" for all users.
But, of course, that's a matter of a much broader discussion. I don't think your work should be blocked on implementing any of this. I'm just saying that you're not alone in this struggle 😅
https://github.com/llvm/llvm-project/pull/144313
More information about the cfe-commits
mailing list