dblaikie added a comment. In D141451#4312256 <https://reviews.llvm.org/D141451#4312256>, @aaron.ballman wrote:
> In D141451#4311199 <https://reviews.llvm.org/D141451#4311199>, @dblaikie > wrote: > >>> probably too much, but then I wonder "how do we make Fortify work?". >> >> (I'm still sort of on the side of "if the compile-time costs to get more >> verbose diagnostics is high, we could have a low-quality default-on >> diagnostic and it could mention/recommend a different/high >> quality/compile-time costly diagnostic" so for code bases like the Linux >> kernel that rely on this sort of thing a lot, with lots of always_inlining, >> etc, they can tradeoff toward the better diagnostic experience and codebases >> that don't use these features much they can still get the checking for when >> it does come up, but at some cost of quality/awkwardness in needing to >> rebuild with other flags) > > This isn't about verbosity of the diagnostics, though, so much as it's about > user experience. I'd agree that enabling more verbose diagnostic checking is > reasonable to ask users to opt into, but what I'm struggling with is > expecting users to opt into a mode so that the diagnostics appear in the > correct places instead of detached from the source they're noting. Also, with > the `error` and `warning` attributes both being used by glibc (and not just > for fortify source, but as a general part of the interface), I think this is > broader than just inlining decision notes. > >> But if folks decided some more invasive tracking was worth implementing >> (alongside the debug info codepath that already exists but is perhaps too >> slow to be always on) I wouldn't get up on a soapbox to strenuously object - >> I just think it's a bit unfortunate to build a duplicate thing, but maybe >> necessary. > > Agreed on the unfortunateness of duplicating functionality; if we can avoid > that, it'd be best. But I'm not sure we have more ideas on how to accomplish > it, either. Fair enough. Well, hopefully somewhere in the summary of all this is a perf comparison - between the most narrowed down option using the existing DebugLocs and this new/distinct tracking system. But guess it's going that way. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141451/new/ https://reviews.llvm.org/D141451 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
