https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #4) > Yeah, without analyzing what the function call (constructor in this case) > actually does > hard to say whether the warning is ok or not. > Maybe some heuristics based on the types? Yes, I'm about to post another patch in response to <https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610353.html>. > The reference in question is const Plane &, so see if the reference could > bind to some member of the class that is destructed at the end of the > statement (Ref<Plane>) or the class itself? > Even with that there can be false positives and false negatives, > e.g. the to be destructed temporary could contain a pointer to a heap > allocated Plane and return a reference to that and then deallocate it in the > destructor (it would then be a dangling reference that with the change > wouldn't be warned about), or > on the other side, e.g. if the possibly dangling reference is const Whatever > & > and the temporary is Whatever, it might be likely that the reference is to > the > temporary, but it could be just a value of some member of it that would > happen to have that type. It's tricky. I've seen unfixable problems with range-based for loops, for instance.
