llvmorg-github-actions[bot] wrote:
<!--LLVM PR SUMMARY COMMENT--> @llvm/pr-subscribers-clang-tidy Author: Zeyi Xu (zeyi2) <details> <summary>Changes</summary> --- Full diff: https://github.com/llvm/llvm-project/pull/213562.diff 1 Files Affected: - (modified) clang-tools-extra/docs/clang-tidy/checks/abseil/unchecked-statusor-access.md (+3-3) ``````````diff diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/unchecked-statusor-access.md b/clang-tools-extra/docs/clang-tidy/checks/abseil/unchecked-statusor-access.md index b8363edde7ea9..cfb7346711acd 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/abseil/unchecked-statusor-access.md +++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/unchecked-statusor-access.md @@ -11,15 +11,15 @@ An access to the value of an `StatusOr<T>` occurs when one of its `value`, `operator*`, or `operator->` member functions is invoked. To align with common misconceptions, the check considers these member functions as equivalent, even though there are subtle differences -related to exceptions vs. undefined behavior. +related to exceptions vs. undefined behavior. An access to the value of a `StatusOr<T>` is considered safe if and -only if code in the local scope (e.g. function body) ensures that the +only if code in the local scope (e.g. function body) ensures that the status of the `StatusOr<T>` is ok in all possible execution paths that can reach the access. That should happen either through an explicit check, using the `StatusOr<T>::ok` member function, or by constructing the `StatusOr<T>` in a way that shows that its status is unambiguously -ok (e.g. by passing a value to its constructor). +ok (e.g. by passing a value to its constructor). Below we list some examples of safe and unsafe `StatusOr<T>` access patterns. `````````` </details> https://github.com/llvm/llvm-project/pull/213562 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
