================
@@ -10967,16 +10967,27 @@ def warn_lifetime_safety_use_after_free : Warning<
"%select{allocated object|parameter}0 does not live long enough">,
InGroup<LifetimeSafetyUseAfterFree>, DefaultIgnore;
-def warn_lifetime_safety_return_stack_addr
- : Warning<"address of stack memory is returned later">,
- InGroup<LifetimeSafetyReturnStackAddr>,
- DefaultIgnore;
-def warn_lifetime_safety_return_stack_addr_moved
- : Warning<"address of stack memory may be returned later. "
- "This could be false positive as the storage may have been moved. "
- "Consider moving first and then aliasing later to resolve the issue">,
- InGroup<LifetimeSafetyReturnStackAddrMoved>,
- DefaultIgnore;
+def warn_lifetime_safety_return_stack_addr : Warning<
+ "%select{address of|reference to}0 stack memory associated with "
+ "%select{local variable|parameter}2 %1 returned">,
+ InGroup<LifetimeSafetyReturnStackAddr>, DefaultIgnore;
----------------
NeKon69 wrote:
>From my very limited experience, what I don’t really like about doing this is
>that it’s hard to understand how a message will actually look just from
>looking at the diagnostic definition.
Maybe we could instead create an enum for each of the parameters where you have
to select an option? The thing I don’t like about that approach is that we’d
end up with a lot of enums. Or maybe there's a different reason you prefer this
direct string approach?
https://github.com/llvm/llvm-project/pull/199432
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
