| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
CFIndex and NSInteger should be treated the same way (see the section Platform Dependencies).
This diff changes the function shouldNotPrintDirectly in SemaChecking.cpp accordingly
and adds tests for the "fixit" and the warning.
Differential revision: https://reviews.llvm.org/D34496
Test plan: make check-all
llvm-svn: 306343
|
|
|
|
|
|
| |
with objc stuff will be resolved.
llvm-svn: 221829
|
|
|
|
| |
llvm-svn: 221825
|
|
|
|
| |
llvm-svn: 221824
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.
A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.
<rdar://problem/16616623>
llvm-svn: 209966
|
|
|
|
| |
llvm-svn: 177934
|
|
|
|
|
|
| |
Fixes <rdar://problem/13491605>.
llvm-svn: 177931
|
|
|
|
|
|
|
|
|
| |
'long' and 'long long' are different for the purposes of mangling.
This caused <rdar://problem/13254874>.
This reverts commit c2f994d31ec85e9af811af38eb1b28709aef0b2c.
llvm-svn: 175681
|
|
|
|
|
|
| |
<rdar://problem/11540697>
llvm-svn: 175588
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is valid to do this:
printf("%u", (int)x);
But if we see this:
printf("%lu", (int)x);
...our fixit should suggest %d, not %u.
llvm-svn: 172739
|
|
|
|
| |
llvm-svn: 172738
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<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
|
|
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
|