6 Commits

Author SHA1 Message Date
Aaron Ballman
7deaeb2a05 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 fourth batch of tests being updated (there are a significant
number of other tests left to be updated).
2022-02-07 15:29:36 -05:00
Leonard Chan
c72aaf62d3 Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"
Updated with fix for read of uninitialized memory.

llvm-svn: 360109
2019-05-07 03:20:17 +00:00
Leonard Chan
ef2dc25a96 Revert "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"
This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d.

llvm-svn: 359859
2019-05-03 03:28:06 +00:00
Leonard Chan
fc40cbd9d8 [Attribute/Diagnostics] Print macro if definition is an attribute declaration
If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.

We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.

Differential Revision: https://reviews.llvm.org/D51329

llvm-svn: 359826
2019-05-02 20:38:14 +00:00
John McCall
28ea04fc4c Define __unsafe_unretained and __autoreleasing in ObjC GC mode.
This was an accidental regression from the MRC __weak patch.

llvm-svn: 252668
2015-11-10 23:00:25 +00:00
Douglas Gregor
f30053d18d Relax the conversion rules for Objective-C GC qualifiers a
bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.

Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.

Fixes <rdar://problem/9402499>.

llvm-svn: 131065
2011-05-08 06:09:53 +00:00