maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
444,543 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

16 Commits

Author SHA1 Message Date
Aaron Ballman 7de7161304 Use functions with prototypes when appropriate; NFC 
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the sixth batch of tests being updated (there are a significant
number of other tests left to be updated).
 2022-02-09 17:16:10 -05:00
Alexander Shaposhnikov 623513742c [clang] Enable printf check for CFIndex 
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
 2017-06-26 23:02:27 +00:00
Anton Korobeynikov 50a3cbd7c0 Temporary revert r221818 until all the problems 
with objc stuff will be resolved.

llvm-svn: 221829
 2014-11-12 23:15:38 +00:00
Anton Korobeynikov 04348de5d3 Now really fix the typo in the test 
llvm-svn: 221825
 2014-11-12 22:58:08 +00:00
Anton Korobeynikov c427e3de77 Update the tests to handle proper result type of (?:) 
llvm-svn: 221824
 2014-11-12 22:48:38 +00:00
Jordan Rose bc53ed1ee6 Format strings: check against an enum's underlying type. 
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
 2014-05-31 04:12:14 +00:00
Ted Kremenek 30b77bf737 Fix testcase. 
llvm-svn: 177934
 2013-03-25 23:05:40 +00:00
Ted Kremenek cd3d440b82 For printf checking, handle nested typedefs for darwin-specific checking. 
Fixes <rdar://problem/13491605>.

llvm-svn: 177931
 2013-03-25 22:28:37 +00:00
Jordan Rose 011bda8031 Revert "intmax_t is long long on Darwin, not long." 
'long' and 'long long' are different for the purposes of mangling.
This caused <rdar://problem/13254874>.

This reverts commit c2f994d31ec85e9af811af38eb1b28709aef0b2c.

llvm-svn: 175681
 2013-02-20 22:28:41 +00:00
Jordan Rose e2b34142c3 intmax_t is long long on Darwin, not long. 
<rdar://problem/11540697>

llvm-svn: 175588
 2013-02-20 01:56:21 +00:00
Jordan Rose aa7a3b3e75 Format strings: correct signedness if already correcting width (%d,%u). 
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
 2013-01-17 18:47:16 +00:00
Jordan Rose b169ccc118 Convert test/FixIt/format-darwin.m to use relative line numbers. 
llvm-svn: 172738
 2013-01-17 18:47:12 +00:00
Jordan Rose ea0fdfe146 Format strings: add more expression types that don't need parens to cast. 
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
 2012-12-05 18:44:44 +00:00
Jordan Rose 4c266aa371 Format strings: offer a fixit for Darwin's %D/%U/%O to ISO %d/%u/%o. 
<rdar://problem/12061922>

llvm-svn: 163772
 2012-09-13 02:11:15 +00:00
Jordan Rose 510260c2bf Format strings: %D, %U, and %O are valid on Darwin (same as %d, %u, %o). 
These will warn under -Wformat-non-iso, and will still be rejected
outright on other platforms.

<rdar://problem/12061922>

llvm-svn: 163771
 2012-09-13 02:11:03 +00:00
Jordan Rose aee3438195 Format strings: suggest casts for NS(U)Integer and [SU]Int32 on Darwin. 
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
 2012-09-05 22:56:26 +00:00