| Issue |
135045
|
| Summary |
[clang-tidy] `bugprone-unchecked-optional-access`: support detection of unsafe `std::expected` access
|
| Labels |
clang-tidy
|
| Assignees |
|
| Reporter |
BaLiKfromUA
|
I'd like to propose extending the existing clang-tidy check `bugprone-unchecked-optional-access` to also detect unsafe access to `std::expected<T, E>` values.
Just like `std::optional<T>`, `std::expected<T, E>` requires validation (e.g. via `.has_value()` or `operator bool()`) before accessing the contained value via `.value()`, `operator*()`, or `operator->()`. The same kind of misuse patterns apply and can be caught using `bugprone-unchecked-optional-access` .
>From my experience with `bugprone-unchecked-optional-access` implementation, code change should be quite straightforward.
**I am planning to work on draft PR in upcoming weeks, but want to start this issue to gather feedback**. I tried to search for existing opened issues but didn't find any.
Main questions for me:
- Would it make sense to include this support directly in `bugprone-unchecked-optional-access`, or would a new check like `bugprone-unchecked-expected-access` be preferable?
- Are there any `std::expected`-specific behaviors or edge cases I may have overlooked?
If we are happy to start supporting `std::expected<T, E>`, IMO we also should support `tl::expected<T,E>` [Link](https://github.com/TartanLlama/expected) because it is widely used in codebases which don't use C++ 23.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
