<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 5, 2015 at 2:51 PM, Marek Kurdej <span dir="ltr"><<a href="mailto:curdeius@gmail.com" target="_blank">curdeius@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<br><div>As Alex has stated already, the problem lies in the fact that the code doesn't handle macros.</div><div>That wasn't an attempt to avoid breaking code, but rather a question of simplicity and lack of knowledge about clang-tidy's way of handling macros.</div><div>I'll take a look at it in my spare time this weekend and give you more feedback about what can be done.</div><div>I've just seen that twice in the code, the check returns immediately if it encounters a macro.</div></div></blockquote><div><br></div><div>It's the easiest way to avoid messing up code in macros (it was probably me who suggested inserting this check), but there may be a more accurate way to do this that won't lead to completely failing to insert braces when a statement is a single macro expansion.</div><div><br></div><div>As a possible way to solve this, I'd suggest trying to check if both locations where the braces are going to be inserted are on the same level of macro expansion in the same file. Lexer::makeFileCharRange is a rather advanced method that could help here.</div><div><br></div><div>In any case, it makes sense to continue the discussion (if any) on <a href="http://llvm.org/PR22785" target="_blank">llvm.org/PR22785</a>.</div><div><br></div><div>-- Alex</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Best regards,</div><div>Marek</div></div><br><div class="gmail_quote">Le mer. 4 mars 2015 à 12:31, Alexander Kornienko <<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>> a écrit :<div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>+<a href="mailto:curdeius@gmail.com" target="_blank">curdeius@gmail.com</a></div><div><br></div>I found this thread while searching for something else in the list archive.<div><br></div><div>This report would definitely be more visible on <a href="http://llvm.org/bugs" target="_blank">llvm.org/bugs</a>, I've filed it as <a href="http://llvm.org/PR22785" target="_blank">llvm.org/PR22785</a>.</div><div><br></div><div>The issue has nothing to do with the Clang's treatment of macros in -Wundefined-bool-conversion/-Wtautological-undefined-compare diagnostics. It's just an over-eager attempt to avoid breaking the code by messing with macros.</div><div><br></div><div>Marek (cc-ed here) is the author of the corresponding check. Maybe he'll be interested in fixing the issue.</div><div><br></div><div>-- Alex</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 10, 2014 at 1:59 PM, miroslav.fontan <span dir="ltr"><<a href="mailto:miroslav.fontan@wincor-nixdorf.cz" target="_blank">miroslav.fontan@wincor-nixdorf.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Thanks for the -save-temps hint, it helps with this particular issue,<br>
unfortunatelly it does not solve the cause of the problem.<br>
<br>
I guess that Clang-based tools inherit the same macro treatment from clang<br>
parser and give an inaccurate results.<br>
<br>
For example this code fragment is handled incorrectly by command: clang-tidy<br>
-check=-*,readability-braces-around-statements -fix<br>
<br>
#define MACRO_1 i++<br>
#define MACRO_2<br>
<br>
void test(int i)<br>
{<br>
if( i % 3) i--; // OK<br>
else if( i % 2) MACRO_1; // KO, no braces<br>
else MACRO_2; // OK<br>
}<br>
<br>
Maybe I am stubborn, I still think that preprocess step should be made<br>
completely before the next steps.<br>
<br>
Best regards<br>
<br>
Mira<br>
<span><br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a>]<br>
</span><span>> On Behalf Of Joerg Sonnenberger<br>
> Sent: Wednesday, November 05, 2014 12:20 PM<br>
> To: <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> Subject: Re: [cfe-dev] Warnings not raised from a macro: -Wundefined-<br>
> bool-conversion/-Wtautological-undefined-compare<br>
><br>
</span><div><div>> On Wed, Nov 05, 2014 at 11:58:55AM +0100, miroslav.fontan wrote:<br>
> > I think Martin is right. Preprocessor is only textual replacement,<br>
> > compiler should not know about this step and compiles code resulting<br>
> > from preprocess step.<br>
><br>
> A lot of people disagree. If you want to force it to give all warnings,<br>
> use -save-temps.<br>
><br>
> Joerg<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>
</div></div></div>
</blockquote></div></div></div>
</blockquote></div><br>
</div></div>