<div dir="ltr"><div>Good time of day!<br><br>First of all I would like to show cases I've included in current test:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>const char *str = "abc";<br></div><div>bool b = str; // no-warning<br>...<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>return str; // warning<br>...<br></div><div>return b; // no-warning</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>bool implStrCast() {<br>return "" // warn<br>}<br></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>const char *text() {<br></div><div>return "some text";<br>}<br><br></div><div>bool implBoolCast() {<br></div><div>return text(); // warning<br></div><div>}<br><br></div><div>bool explBoolCast() {<br></div><div>bool r = text(); // no-warning<br></div><div>return r; // no-warning<br></div><div>}<br></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>bool implFlootCast() {<br></div><div>return 1.; // warning<br></div><div>}<br></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>bool explBoolCast2() {<br></div><div>return text() == 0; // no-warning<br></div><div>}<br></div></blockquote><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>bool boolProxy(int _, bool x, bool y);<br>...<br></div>boolProxy(1, getInteger(), (bool)1); // warn (only for second arg)<br></blockquote></div><div> <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im">I'd really like to know more about the approach you've taken with this checker. </span></blockquote></div><div>Current implementation checks 2 types of statements: CallExpr & ReturnStmt.<br></div><div>First one actually aimed to check unexpected implicit casts of arguments passed to CallExpr (last example code). ReturnStmt for other presented cases. I could attach diff if it's appropriate here.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im">Nowadays we try to make each test file correspond to a single checker.</span></blockquote><div>I'll consider separation of new checker into new one (including dedicated tests of course).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail-im">But i don't think that there is a need for special code
 in the checker that detects testing environment and changes the 
behavior.</span></div></blockquote><div>I meant detecting & ignoring just special Calls (such as mentioned <i>clang_analyzer_eval</i>) only if we running in test env.<br><i></i></div><br></div><div>Thanks, Alexey<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-30 19:34 GMT+03:00 Artem Dergachev <span dir="ltr"><<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(forgot to add cfe-dev on reply, re-replying, sry)<span class=""><br>
<br>
Hello,<br>
<br>
I'd really like to know more about the approach you've taken with this checker. What kinds of conversions does it flag? Eg.:<br>
<br>
bool foo() {<br>
  return ""; // warn.<br>
  // or...<br>
  char *str1 = "";<br>
  return str1; // warn?<br>
  // or...<br>
  char *null_str = 0;<br>
  return null_str; // nope.<br>
}<br>
<br>
It's not clear to me why would it warn on converting something to an int. In C, there doesn't seem to be an easy way to discriminate between int and boolean types. You might eventually want to hardcode a list of common library functions that treat their int arguments as boolean flags. And even if we have platform/library-specific typedefs such as ObjC BOOL, they are usually quite distinct from plain ints (eg. by typedef sugar).<br>
<br>
Then, ideally new checkers shouldn't be enabled on existing tests. Nowadays we try to make each test file correspond to a single checker. So you're running into a problem that arises because we didn't take this approach before, so we have some tests that have the whole alpha.core enabled (which is gross).<br>
<br>
If you're running into existing test file with a lot of eg. clang_analyzer_eval(BOOL) calls, and many of those suddenly get flagged, i think these are true positives. The checker works as intended, and we could just add expected-warnings on these lines. If there are too many such lines, i'd probably suggest to disable the checker for this file, i.e. adding -analyzer-disable-checker=alph<wbr>a.core.YourChecker to the run-line at the top of the file. Separate files for the checker should be enough.<br>
<br>
But i don't think that there is a need for special code in the checker that detects testing environment and changes the behavior. After all, that defeats the purpose of testing.<br>
<br>
On 11/29/17 12:20 PM, Alexey Knyshev via cfe-dev wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone!<br>
<br>
I have implemented a prototype of "different.ConversionToBool(C, C++)".<br>
According to list of potential checkers (<a href="https://clang-analyzer.llvm.org/potential_checkers.html" rel="noreferrer" target="_blank">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a> <<a href="https://clang-analyzer.llvm.org/potential_checkers.html" rel="noreferrer" target="_blank">https://clang-analyzer.llvm.o<wbr>rg/potential_checkers.html</a>>) I've implemented it as the part of existing alpha.core.BoolAssignment checker. There is one problem I've faced while testing changes via llvm-lit. There are many FnChecks calls like /clang_analyzer_eval/ in Analysis/casts.[c/m] which are called with integer arguments instead of bool according declaration. Obviously it leads to false positives in implemented checker (implicit cast to boolean). Actually, the question is: What is the best way to avoid such false-positives? I came up with the following possible solutions:<span class=""><br>
<br>
1. Is there way to distinguish FnCheck CallExpr from common CallExpr (any flag or whatever). If so, it's quite simple to ignore them in the checker.<br></span>
2. Is there way to determine if checker is running in testing env? And afterwards filter any calls to FnChecks like/clang_analyzer_eval /by name. As it was implemented in /CStringChecker:evalCall/.<br>
3. Add special FnCheck like /clang_analyser_eval_implicit_<wbr>cast(bool)/ which is supposed to replace /clang_analyzer_eval /in cast tests.<span class=""><br>
<br>
Any suggestions?<br>
<br>
Thanks, Alexey K<br>
<br>
-- <br>
</span><span class=""><a href="http://linkedin.com/profile" rel="noreferrer" target="_blank">linkedin.com/profile</a> <<a href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw" rel="noreferrer" target="_blank">https://www.linkedin.com/prof<wbr>ile/view?id=AAMAABn6oKQBDhBtei<wbr>QnWsYm-S9yxT7wQkfWhSw</a>><br>
<br>
<a href="http://github.com/alexeyknyshev" rel="noreferrer" target="_blank">github.com/alexeyknyshev</a> <<a href="http://github.com/alexeyknyshev" rel="noreferrer" target="_blank">http://github.com/alexeyknysh<wbr>ev</a>><br>
<a href="http://bitbucket.org/alexeyknyshev" rel="noreferrer" target="_blank">bitbucket.org/alexeyknyshev</a> <<a href="https://bitbucket.org/alexeyknyshev/" rel="noreferrer" target="_blank">https://bitbucket.org/alexeyk<wbr>nyshev/</a>><br>
<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</span></blockquote>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw" target="_blank">linkedin.com/profile</a><br><br><a href="http://github.com/alexeyknyshev" target="_blank">github.com/alexeyknyshev</a><span></span><a href="http:///" target="_blank"></a><span></span><br><a href="https://bitbucket.org/alexeyknyshev/" target="_blank">bitbucket.org/alexeyknyshev</a><br></div></div>
</div>