[clang] [clang] Fix dangling false positives for conditional operators. (PR #120233)

[Haojian Wu via cfe-commits]

================
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath &Path, Expr *Call,
     //   Temp().ptr; // Here ptr might not dangle.
     if (isa<MemberExpr>(Arg->IgnoreImpCasts()))
       return;
+    // Avoid false positives when the object is constructed from a conditional
+    // operator argument. A common case is:
+    //   // 'ptr' might not be owned by the Owner object.
+    //   std::string_view s = cond() ? Owner().ptr : sv;
----------------
hokein wrote:

> I am a bit confused to be honest. Are there any other contexts where `Owner().ptr` is problematic? I'd expect our analysis to behave the same for a subexpression like that regardless the context. So I am surprised we need to insert special logic for the ternary operator.

Possibly, but I don’t know of any concrete examples (it’s hard to judge). We have another ad-hoc filter at the end, `IsGslPtrValueFromGslTempOwner`, which filters out cases where the GSL pointer doesn’t originate from a GSL owner. This works well for simple and common cases, but when combined with `lifetimebound`, the behavior becomes tricky. 

The current fix extends the `MemberExpr` logic (L583) to handle cases like `GSLPointer pointer(Owner().ptr);`, but it doesn’t yet address cases like `GSLPointer pointer(Cond ? Owner().ptr : GSLPointer());`. I think this fix is a reasonable extension to address the issue.


https://github.com/llvm/llvm-project/pull/120233