[llvm-bugs] [Bug 25769] New: -Wparentheses could give a smarter diagnostic if one of the operators is bitwise & or | and the operands have type `bool`
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Dec 7 19:12:10 PST 2015
https://llvm.org/bugs/show_bug.cgi?id=25769
Bug ID: 25769
Summary: -Wparentheses could give a smarter diagnostic if one
of the operators is bitwise & or | and the operands
have type `bool`
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangbugs at nondot.org
Reporter: richard-llvm at metafoo.co.uk
CC: llvm-bugs at lists.llvm.org, rtrieu at google.com
Classification: Unclassified
Today I saw this:
tools/clang/lib/AST/ExprConstant.cpp:8866:49: warning: & has lower precedence
than <; < will be evaluated first [-Wparentheses]
(SEK < Expr::SE_AllowUndefinedBehavior & Result.HasUndefinedBehavior);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
tools/clang/lib/AST/ExprConstant.cpp:8866:49: note: place parentheses around
the '<' expression to silence this warning
(SEK < Expr::SE_AllowUndefinedBehavior & Result.HasUndefinedBehavior);
^
( )
tools/clang/lib/AST/ExprConstant.cpp:8866:49: note: place parentheses around
the & expression to evaluate it first
(SEK < Expr::SE_AllowUndefinedBehavior & Result.HasUndefinedBehavior);
^
( )
This is pretty good, but we could be smarter here: we have a bitwise & operator
where both operands are of type 'bool'. In that case, we should guess that the
user did actually mean an 'and' operator, and suggest changing it to '&&'
(unless the RHS has side-effects, in which case maybe suggesting parens is the
right thing).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151208/dc2fa98a/attachment.html>
More information about the llvm-bugs
mailing list