Moving discussion to the list:
NoQ added a comment.
~*sorry for hijacking review with this, we should move this conversation to
the list*~In ⚙ D46159 [clang-tidy] Add a flag to enable alpha checkers, @pfultz2 wrote:
>
> I am definitely interested in working on getting some of the checkers
> stable, and have already started some work on expanding the
> ConversionChecker, but would like user feedback as I move forward.Yay! I would most likely have a chance to help out with final evaluation of
checkers before they move out of alpha.In ⚙ D46159 [clang-tidy] Add a flag to enable alpha checkers, @pfultz2 wrote:
>
> Some like the Conversion checker doesn't seem to have any issues(because
> its fairly limited at this point).Last time i tried it, it was very hard to understand positives produced by
the checker. It seems that it needs to implement a relatively sophisticated
"bug visitor" in order to explain why does it think that a certain
conversion would overflow by highlighting the respective spot somewhere in
the middle of the path. It is especially important when the value comes from
an inlined function because the analyzer wouldn't draw paths through all
inlined functions (it would have been overwhelming) unless something
interesting happens in there.
Initially, I am thinking of showing the path for a variable(ie DeclRef) in the
expression, which should be better than showing the path for the implicit
cast. For multiple variables, perhaps trying to show the variable with the
longest path, as perhaps that is more interesting.
Although, there could be cases were the interesting path is from something
else.
Then somebody would need to have a look at intentional overflows and if it's
possible to avoid them.
I am considering not warning when its an integral constant expression. There
are too many places where the user explicitly underflows. Instead a clang-tidy
check or warning could provide a check for such conversions instead.