[[gsl::Pointer]] does not diagnose dangling-after-copy

[pkasting]

[[gsl::Pointer]] can be used to diagnose a limited set of dangling pointer issues. However, it does not seem to preserve lifetime info through copies; see https://godbolt.org/z/vfjojda7K. Since the docs say a class so annotated "behaves like a pointer into the owner", it seems like copied "pointer"s should also dangle when the original owner is destroyed.

#include <optional>

struct [[gsl::Owner]] T {};

struct [[gsl::Pointer]] S {
  S(const T&);
};

S f1() {
  T t;
  return S(t);  //-Wreturn-stack-address, yay
}

S f2() {
  T t;
  S s(t);
  return s;  // No -Wreturn-stack-address, boo
}

std::optional<S> f3() {
  T t;
  return S(t);  // No -Wreturn-stack-address, boo
}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (pkasting)

[[gsl::Pointer]] can be used to diagnose a limited set of dangling pointer issues. However, it does not seem to preserve lifetime info through copies; see https://godbolt.org/z/vfjojda7K. Since the docs say a class so annotated "behaves like a pointer into the owner", it seems like copied "pointer"s should also dangle when the original owner is destroyed.

[hokein]

For f2(), it requires some form of reference tracking, as we need to ensure that the s in the return statement still points to the local owner t. However, this kind of tracking goes beyond the current statement-local analysis.

For f3(), we've added some support for detecting dangling issues in cases involving Container<Pointer>. While the original case is not diagnosed, if the explicit S is removed, Clang will detect it:

std::optional<S> f3() {
  T t;
  return t;  // clang emits -Wreturn-stack-address
}

Clang doesn't guarantee catching all dangling issues. The design intentionally prioritizes achieving a nearly-zero false-positive rate, but this comes at the cost of a high false-negative rate.