https://github.com/zeyi2 created https://github.com/llvm/llvm-project/pull/213562
None >From f93634de44ce561e20962268afbf6c10696ef359 Mon Sep 17 00:00:00 2001 From: Zeyi Xu <[email protected]> Date: Mon, 3 Aug 2026 01:52:54 +0800 Subject: [PATCH] [clang-tidy][docs] Replace invisible characters in unchecked-statusor-access. NFC. --- .../clang-tidy/checks/abseil/unchecked-statusor-access.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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. _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
