[PATCH] D31097: [clang-tidy] don't warn about implicit widening casts in function calls

[Daniel Marjamäki via Phabricator via cfe-commits]

danielmarjamaki added a comment.



In https://reviews.llvm.org/D31097#704628, @alexfh wrote:

> In https://reviews.llvm.org/D31097#704626, @alexfh wrote:
>
> > In https://reviews.llvm.org/D31097#704621, @xazax.hun wrote:
> >
> > > I wonder whether warning on implicit casts still makes sense for example in mission critical code. So maybe it is worth to have a configuration option with the default setting being less strict and chatty. What do you think?
> >
> >
> > But it's not about "misplaced casts", it's about implicit conversions and -Wconversion diagnostic can take care of this.
>
>
> Actually, the diagnostics about implicit casts here might be useful (but maybe in a separate check). I have to look again at https://reviews.llvm.org/D17987.


there can definitely be bugs when there are such implicit casts.

but this checking has no precision at all. I am against that we don't care about precision.

adding casts to silence such warnings are dangerous too. I have seen for instance in Clang repo when there is "loss of sign" warning and the developer fix that by casting for instance a "size_t" to "int" and then there is logically loss of precision.

In https://reviews.llvm.org/D31097#704626, @alexfh wrote:

> In https://reviews.llvm.org/D31097#704621, @xazax.hun wrote:
>
> > I wonder whether warning on implicit casts still makes sense for example in mission critical code. So maybe it is worth to have a configuration option with the default setting being less strict and chatty. What do you think?
>
>
> But it's not about "misplaced casts", it's about implicit conversions and -Wconversion diagnostic can take care of this.


I agree..

Just want to advertise the analyzer ConversionChecker also in case you didn't know about it. That is supposed to be a precise checker for loss of precision and loss of sign. It does not detect this loss of precision in implicit casts but I would like that is taken care of.


Repository:
  rL LLVM

https://reviews.llvm.org/D31097