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.