[clang] [llvm] [Clang] Show inlining hints for __attribute__((warning/error)) (PR #174892)

[Nick Desaulniers via cfe-commits]

nickdesaulniers wrote:

Hey, sorry for [suggesting](https://github.com/llvm/llvm-project/pull/174892#issuecomment-3753254069) we elide `-fdiagnostics-show-inlining-chain`, i.e.

> In that case, @JustinStitt WDYT about just attaching the note about -gline-directives-only to WarningAttr (and thus eliding the addition of -fdiagnostics-show-inlining-chain?

_then stepping away from upstream reviews here for over 2 months_.  I'm back at Google now, managing Android's LLVM team, so I should have more time for reviews now (famous last words).

> but otherwise I want it off by default.

Understandable; don't pay for what you don't use.  I guess I didn't consider that perspective enough when I made my above sugguestion.  In that case, we'd need to _go back to having an explicit flag (`-fdiagnostics-show-inlining-chain`)_ that we could keep off by default, then the Linux kernel could enable explicitly via feature detecting support for the command line flag.

>> I think ~1% memory overhead is acceptable given the benefits
>> I think these attributes are used outside of the kernel too.
> A large fraction of those uses are using it in a way that doesn't benefit from this patch.

I agree with @efriedma-quic here; the point is really to help someone writing code that calls libc standard library functions that have a _particular implementation of FORTIFY_SOURCE_.  It's conceivable that other libc implementations don't have FORTIFY_SOURCE, or their implementation wouldn't benefit from this. Also conceivable that these inline hints are helpful for other diagnostics than `-Wwarning`/`-Werror`, but that's a stretch.

---
So, again, sorry for derailing this with a half baked suggestion, then running off.

Perhaps if @efriedma-quic and @AaronBallman could agree with us going back to having an explicit off-by-default `-fdiagnostics-show-inlining-chain` and @JustinStitt doesn't mind going back to that version, then that would be a compromise that makes everyone happy, so that we can unstick this, and we can better help Linux kernel developers better spot their known at compile time bounds overflows?

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