alexfh added a comment.
Sorry for the delay. Your patch was lost in my inbox. Feel free to ping me
earlier.
================
Comment at: docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst:37
@@ +36,3 @@
+
+It turns out that the common bug is to have function returning only bools but
having int as return type.
+If check finds case like this then it function return type to bool.
----------------
Prazek wrote:
> alexfh wrote:
> > It may well not be a bug. It's definitely not a bug for `extern "C"`
> > functions and functions in C code. We definitely don't need to change the
> > function return type, since it's a rather involved change (and clang-tidy
> > checks currently are simply not able to make such change correctly in case
> > of a function with external linkage). So please remove this automated fix.
> This check runs only on C++ functions. Maybe checking that the function
> isExternC() would be enough?
As I've said, extern "C" is not the only way to make a function a part of an
API exposed to external users.
================
Comment at: test/clang-tidy/bugprone-bool-to-integer-conversion.cpp:192
@@ +191,3 @@
+ // CHECK-FIXES: bool yat2() {
+
+ auto l = []() {
----------------
Prazek wrote:
> Why it is dangerous? What I see after runnign on llvm code base, that it is
> one of the most frequent case.
> The only bug is the extern "C" thing.
Well, `extern "C"` is not the only way to expose functions to some external
code. This fix potentially changes ABI, which is generally not a safe thing to
do. I think, we should make the fix optional.
http://reviews.llvm.org/D18821
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
