================ @@ -0,0 +1,377 @@ +.. title:: clang-tidy - abseil-unchecked-statusor-access + +abseil-unchecked-statusor-access +================================ + +This check identifies unsafe accesses to values contained in +``absl::StatusOr<T>`` objects. Below we will refer to this type as +``StatusOr<T>``. + +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. + +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 +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). + +Below we list some examples of safe and unsafe ``StatusOr<T>`` access +patterns. + +Note: If the check isn’t behaving as you would have expected on a code +snippet, please `report it <http://github.com/llvm/llvm-project/issues/new>`__. + +False negatives +--------------- + +This check generally does **not** generate false negatives. If it cannot ---------------- jvoung wrote:
Is there a better phrasing than "generate" false negatives? If the check has false negatives then it **won't** generate any report? Also, the "If it cannot prove an access safe..." do you mean the opposite? "If it cannot prove an access unsafe..." ? https://github.com/llvm/llvm-project/pull/171188 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
