__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
and the programmer intended to write 'sizeof(*p)'. There are several
elements to the new version:
1) The actual expressions are compared in order to more accurately flag
the case where the pattern that works for an array has been used, or
a '*' has been omitted.
2) Only do a loose type-based check for record types. This prevents us
from warning when we happen to be copying around chunks of data the
size of a pointer and the pointer types for the sizeof and
source/dest match.
3) Move all the diagnostics behind the runtime diagnostic filter. Not
sure this is really important for this particular diagnostic, but
almost everything else in SemaChecking.cpp does so.
4) Make the wording of the diagnostic more precise and informative. At
least to my eyes.
5) Provide highlighting for the two expressions which had the unexpected
similarity.
6) Place this diagnostic under a flag: -Wsizeof-pointer-memaccess
This uses the Stmt::Profile system for computing #1. Because of the
potential cost, this is guarded by the warning flag. I'd be interested
in feedback on how bad this is in practice; I would expect it to be
quite cheap in practice. Ideas for a cheaper / better way to do this are
also welcome.
The diagnostic wording could likely use some further wordsmithing.
Suggestions welcome here. The goals I had were to: clarify that its the
interaction of 'memset' and 'sizeof' and give more reasonable
suggestions for a resolution.
An open question is whether these diagnostics should have the note
attached for silencing by casting the dest/source pointer to void*.
llvm-svn: 133155
argument types for mem{set,cpy,move}. Character pointers, much like void
pointers, often point to generic "memory", so trying to check whether
they match the type of the argument to 'sizeof' (or other checks) is
unproductive and often results in false positives.
Nico, please review; does this miss any of the bugs you were trying to
find with this warning? The array test case you had should be caught by
the array-specific sizeof warning I think.
llvm-svn: 133136
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
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
checking both the source and the destination operands, renaming the
warning group to -Wnon-pod-memaccess and tweaking the diagnostic text
in the process.
llvm-svn: 130786
definition of POD. Specifically, this allows certain non-aggregate
types due to their data members being private.
The representation of C++11 POD testing is pretty gross. Any suggestions
for improvements there are welcome. Especially the name
'isCXX11PODType()' seems truly unfortunate.
llvm-svn: 130492
a destination pointer that points to a non-POD type. This can flag such
horrible bugs as overwriting vptrs when a previously POD structure is
suddenly given a virtual method, or creating objects that crash on
practically any use by zero-ing out a member when its changed from
a const char* to a std::string, etc.
llvm-svn: 130299
rewriting the literal when the value is integral. It is not uncommon to
see code written as:
const int kBigNumber = 42e5;
Without any real awareness that this is no longer an ICE. The note helps
automate and ease the process of fixing code that violates the warning.
llvm-svn: 129243
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
enumeration type to another in C, classify enumeration constants as if
they had the type of their enclosing enumeration. Fixes
<rdar://problem/9116337>.
llvm-svn: 127514
in the LLVM test suite, this function was consuming 7.4% of -fsyntax-only time. This change fixes this issue
by delaying the check that the warning would be issued within a system macro by as long as possible. The
main negative of this change is now the logic for this check is done in multiple places in this function instead
of just in one place up front.
llvm-svn: 127425
don't let calls to such functions go down the normal type-checking path.
Test this out with __builtin_classify_type and __builtin_constant_p.
llvm-svn: 126539
especially C++ code, and generally expand the test coverage.
Logic adapted from a patch by Kaelyn Uhrain <rikka@google.com> and
another Googler.
llvm-svn: 125775
specifically targets literals which are implicitly converted, a those
are more often unintended and trivial to fix. This can be especially
helpful for diagnosing what makes 'const int x = 1e6' not an ICE.
Original patch authored by Jim Meehan with contributions from other
Googlers and a few cleanups from myself.
llvm-svn: 125745
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
Douglas Gregor