Commit Graph

6 Commits

Author SHA1 Message Date
Nico Weber bac8b6b39a -Wdynamic-class-memaccess: Also warn about array types.
It looks like not warning on this was an oversight in the original
implementation of this warning.

llvm-svn: 232900
2015-03-21 17:56:44 +00:00
Reid Kleckner 5fb5b12d48 Extend -Wdynamic-class-memaccess to records containing dynamic classes
Reviewers: rtrieu

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D4325

llvm-svn: 211972
2014-06-27 23:58:21 +00:00
Rafael Espindola 5cab029e4b Don't get confused if a extern "C" builtin function is redeclared without
the extern "C".

llvm-svn: 171260
2012-12-30 17:23:09 +00:00
Matt Beaumont-Gay 335e653fe6 Improve the correctness and accuracy of the message for -Wdynamic-class-memaccess
llvm-svn: 138074
2011-08-19 20:40:18 +00:00
Douglas Gregor 18739c343c Teach the warning about non-POD memset/memcpy/memmove to deal with the
__builtin_ versions of these functions as well as the normal function
versions, so that it works on platforms where memset/memcpy/memmove
are macros that map down to the builtins (e.g., Darwin). Fixes
<rdar://problem/9372688>.

llvm-svn: 133173
2011-06-16 17:56:04 +00:00
Chandler Carruth ac6872655b Clean up the "non-POD memaccess" stuff some. This adds a properly named
diagnostic group to cover the cases where we have definitively bad
behavior: dynamic classes.

It also rips out the existing support for POD-based checking. This
didn't work well, and triggered too many false positives. I'm looking
into a possibly more principled way to warn on the fundamental buggy
construct here. POD-ness isn't the critical aspect anyways, so a clean
slate is better. This also removes some silliness from the code until
the new checks arrive.

llvm-svn: 132534
2011-06-03 06:23:57 +00:00