https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118568

            Bug ID: 118568
           Summary: Diagnosing more dangling references
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider the following simple program which tries to figure out what situations
get dangling reference warnings:

#include <tuple>
#include <utility>

template <class T>
struct X {
    T t;
};

template <class R, class T> auto foo(T const&, T const&) -> R;

int main() {
    [[maybe_unused]] auto const& a = foo<int const&>(1, 2);                    
     // warns
    [[maybe_unused]] auto const& b = foo<X<int const&>>(1, 2);                 
     // warns
    [[maybe_unused]] auto        c = foo<X<int const&>>(1, 2);                 
     // does not warn

    [[maybe_unused]] auto const& d = foo<std::tuple<int const&>>(1, 2);        
     // does not warn
    [[maybe_unused]] auto        e = foo<std::pair<int const&, int const&>>(1,
2);   // warns
    [[maybe_unused]] auto        f = foo<std::tuple<int const&, int const&>>(1,
2);  // does not warn
}

Ideally, I would get a warning on all of these. I'm guessing there are some
heuristics hard-coded to try to reduce the false positive rate, since otherwise
c, e, and f are basically the same thing but only e warns. Likewise, b and c
are the same, since b is just a reference bound to a temporary, but only b
warns. 

clang has an attribute for this specific scenario, [[clang::lifetimebound]].
Annotating the two parameters to foo() means I can get warnings on all six.
Which is nice, but also a fairly narrow situation though. There was an LLVM
thread once upon a time
(https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377/1) to make
it more generally useful but I'm not sure what came of it.

Reply via email to