| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 220763
|
| |
|
|
|
|
|
| |
The code used getLocStart() instead of getLocEnd(). This works for single
token expressions, but breaks if the expression is longer.
llvm-svn: 216306
|
| |
|
|
|
|
|
| |
with the silence fix-it comes first. This is more consistent with the rest
of the warnings in -Wparentheses.
llvm-svn: 179742
|
| |
|
|
| |
llvm-svn: 179740
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will fire on code such as:
cout << x == 0;
which the compiler will intrepret as
(cout << x) == 0;
This warning comes with two fixits attached to notes, one for parentheses to
silence the warning, and another to evaluate the comparison first.
llvm-svn: 179662
|
| |
|
|
|
|
|
|
|
|
| |
These run lines originally tested that the fix-its were properly applied.
Originally, the fixits were attached to warnings and were applied by -fixit.
Now, the fixits are attached to notes, so nothing happens. These run lines
still manage to pass since Clang will produce an empty output which gets piped
back to Clang. Then Clang produces no error on an empty input.
llvm-svn: 179131
|
| |
|
|
|
|
|
|
|
| |
Post-Inc can occur as a binary call (the infamous dummy int argument), but it's
not really a binary operator.
Fixes PR15628.
llvm-svn: 178412
|
| |
|
|
|
|
| |
Suggestion from Matt Beaumont-Gay reviewing r165283.
llvm-svn: 166296
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.
(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)
llvm-svn: 165283
|
| |
|
|
|
|
|
| |
Fixes PR10898. The warning should be silent when there are parenthesis
around the condition expression.
llvm-svn: 139492
|
| |
|
|
|
|
|
| |
expression of '?:'. Add a test case for this pattern, and also test the
code that led to the crash in a "working" case as well.
llvm-svn: 133523
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pretty. In particular this makes it much easier for me to read messages
such as:
x.cc:42: ?: has lower ...
Where I'm inclined to associate the third ':' with a missing column
number, but in fact column numbers have been turned off. Similar
punctuation collisions happened elsewhere as well.
llvm-svn: 133121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r132565, and should address the rest of PR9969:
Warn about cases such as
int foo(A a, bool b) {
return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}
also when + is an overloaded operator call.
llvm-svn: 132784
|
|
|
Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.
This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969
llvm-svn: 132565
|
