[clang-tools-extra] [clang-tidy][docs] Replace invisible characters in unchecked-statusor-access. NFC. (PR #213562)

[via cfe-commits]

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