| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
weak reference.
Thanks to Jordan Rose and John McCall for their sage code review.
Fixes <rdar://problem/12569201>.
llvm-svn: 170864
|
|
|
|
|
|
|
|
| |
This is just a minor bit of refactoring, but it is nice cleanup for
the subsequent patch that adds warning support for assigning literals
to weak variables.
llvm-svn: 170863
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.
(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)
This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.
<rdar://problem/11982013>
llvm-svn: 169400
|
|
|
|
|
|
|
| |
No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).
llvm-svn: 169399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.
There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.
In C++, the type of a character literal is 'char', and so this problem
doesn't exist.
<rdar://problem/12282316>
llvm-svn: 169398
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
| |
with a signed fixed type.
<rdar://problem/12780159>.
llvm-svn: 169051
|
|
|
|
| |
llvm-svn: 168340
|
|
|
|
|
|
|
| |
width of an enum with negative values in IntRange. Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.
llvm-svn: 168126
|
|
|
|
|
|
| |
-Wtautological-constant-out-of-range-compare and added test case.
llvm-svn: 168023
|
|
|
|
|
|
|
|
|
| |
type conversion between integers. This allows the warning to be more accurate.
Also, turned the warning off in an analyzer test. The relavent test cases
are covered by the tests in Sema.
llvm-svn: 167992
|
|
|
|
| |
llvm-svn: 167565
|
|
|
|
|
|
| |
checking against a blacklist.
llvm-svn: 167362
|
|
|
|
| |
llvm-svn: 167358
|
|
|
|
| |
llvm-svn: 165733
|
|
|
|
| |
llvm-svn: 165679
|
|
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|
|
|
|
|
|
|
|
| |
function.
Fixes <rdar://problem/12355298>
llvm-svn: 164988
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also applies to -Wnonnull, -Wtype-safety, and -Wnon-pod-varargs.
All of these can be better checked at instantiation time.
This change does not actually affect regular CallExpr function calls,
since the checks there only happen after overload resolution.
However, it will affect Objective-C method calls.
<rdar://problem/12373934>
llvm-svn: 164984
|
|
|
|
|
|
|
|
|
|
| |
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
llvm-svn: 164855
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
llvm-svn: 164769
|
|
|
|
| |
llvm-svn: 164766
|
|
|
|
| |
llvm-svn: 164454
|
|
|
|
|
|
| |
Richard's comments. // rdar://12202422
llvm-svn: 164316
|
|
|
|
| |
llvm-svn: 164145
|
|
|
|
|
|
|
|
| |
integral expression have the obvious result.
Patch reviewed by John McCall off line.
// rdar://12202422
llvm-svn: 164143
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Retain cycles happen in the case where a block is persisted past its
life on the stack, and the way that occurs is by copying the block.
We should thus look through any explicit copies we see.
Note that Block_copy is actually a type-safe wrapper for _Block_copy,
which does all the real work.
<rdar://problem/12219663>
llvm-svn: 164039
|
|
|
|
|
|
|
| |
C11 7.17's atomic operations. GNU's __atomic_* builtins do allow const-qualified
atomics, though (!!) so don't restrict those.
llvm-svn: 163964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, this should warn:
__block block_t a = ^{ a(); };
Furthermore, this case which previously warned now does not, since the value
of 'b' is captured before the assignment occurs:
block_t b; // not __block
b = ^{ b(); };
(This will of course warn under -Wuninitialized, as before.)
<rdar://problem/11015883>
llvm-svn: 163962
|
|
|
|
|
|
| |
<rdar://problem/12061922>
llvm-svn: 163772
|
|
|
|
|
|
|
|
|
| |
These will warn under -Wformat-non-iso, and will still be rejected
outright on other platforms.
<rdar://problem/12061922>
llvm-svn: 163771
|
|
|
|
|
|
|
| |
As a corollary to the previous commit, even when an extension is
available, we can still offer a fixit to the standard modifier.
llvm-svn: 163453
|
|
|
|
|
|
|
|
|
| |
This seems to be a GNU libc extension; we offer a fixit to %lld on
these platforms.
<rdar://problem/11518237>
llvm-svn: 163452
|
|
|
|
| |
llvm-svn: 163325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These types are defined differently on 32-bit and 64-bit platforms, and
trying to offer a fixit for one platform would only mess up the format
string for the other. The Apple-recommended solution is to cast to a type
that is known to be large enough and always use that to print the value.
This should only have an impact on compile time if the format string is
incorrect; in cases where the format string matches the definition on the
current platform, no warning will be emitted.
<rdar://problem/9135072&12164284>
llvm-svn: 163266
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 163265
|
|
|
|
|
|
|
| |
property-dot syntax is used on an object whose
capture causes retain cycle. // rdar://11702054
llvm-svn: 163017
|
|
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This warns in two specific situations:
1) For potentially swapped function arguments, e.g.
void foo(bool, float);
foo(1.7, false);
2) Misplaced brackets around function call arguments, e.g.
bool InRange = fabs(a - b < delta);
Where the last argument in a function call is implicitly converted
from bool to float, and the function returns a float which gets
implicitly converted to bool.
Patch by Andreas Eckleder!
llvm-svn: 162763
|
|
|
|
|
|
| |
The patch reviewed by Akira Hatanaka.
llvm-svn: 162669
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 162552
|
|
|
|
|
|
|
| |
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
llvm-svn: 162475
|
|
|
|
| |
llvm-svn: 162452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
|
|
|
|
|
|
|
|
|
| |
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
|
|
|
|
|
|
|
|
|
| |
tablegen code, found by -fcatch-undefined-behavior. I would appreciate if
someone more familiar with the NEON code could point me in the direction of how
to write a test for this. We appear to have essentially no test coverage
whatsoever for these builtins.
llvm-svn: 161827
|
|
|
|
| |
llvm-svn: 161527
|
|
|
|
|
|
|
|
| |
This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.
llvm-svn: 161407
|