haoNoQ wrote: @mikhailramalho long time no see!
I think @rniwa is right on this one. "Inline" is completely orthogonal to "safe". Fundamentally it only matters what the function _actually does_; it doesn't matter how it's defined or where or how the code is generated for it. These checkers don't follow our usual paradigm of "false positives are bad". They're coding convention checkers that force WebKit to use smart pointers consistently, even if the compiler hasn't identified any specific memory leaks or use-after-free vulnerabilities to worry about. While it's still valuable to avoid emitting warnings when the code is "obviously safe", they probably wouldn't go for a very approximate reasoning such as "all inline functions are safe" . We do this sort of stuff quite often in the rest of the static analyzer where false positives are much more terrifying than false negatives. But here, WebKit people such as @rniwa have consensually accepted a potentially high "false positive" rate as long as this means getting close to _some real safety_. So this whole "trivial function analysis" thing aggressively treats unknown functions as unsafe by default, and when it actually gets to see the body (which correlates quite a bit with being inline) it carefully inspects it and confirms that it's actually "trivial" enough to not screw memory management. If you turn it off for inline functions, that's pretty close to turning it off entirely. That's probably not what they're looking for. There has to be a more careful solution to the false positves you're seeing. https://github.com/llvm/llvm-project/pull/90733 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
