Age | Commit message (Collapse) | Author |
|
has a single element. This disables the warning in cases where
there is a clear bug, but this is really rare (who uses arrays
with one element?) and it also silences a large class of false
positive issues with C89 code that is using tail padding in structs.
A better version of this patch would detect when an array is in
a tail position in a struct, but at least patch fixes the huge
false positives that are hitting postgres and other code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
refer to 'expansion' instead of 'instantiation'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and to work with pointer arithmetic in addition to array indexing.
The new pointer arithmetic porition of the array bounds checking can be
turned on by -Warray-bounds-pointer-arithmetic (and is off by default).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136046 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM.h imports
them into the clang namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Wsign-compare. Cases that previously warn on this will have a different warning emitted from -Wsign-conversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135664 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
convertToInt(integerParts*) and make them more reliable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135208 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and (while I'm at it) teach it to grok the results of simple
assignments.
The first is PR10336.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135034 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
rdar://problem/9504800
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
objects. // rdar://9495837
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'ownership', not 'lifetime'.
rdar://9477613.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given
const int& r = 1.0;
The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value.
IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133521 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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*.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133155 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133136 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132996 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handle memcpy and memmove. Spotted by Nico.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132534 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This path was reviewed by Chandler Carruth at http://codereview.appspot.com/4538074/
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131793 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
checking both the source and the destination operands, renaming the
warning group to -Wnon-pod-memaccess and tweaking the diagnostic text
in the process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- a default-on warning for pointers to dynamic classes (= classes with vtables)
- a default-off warning for other non-POD types
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'memset' with external linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
may provide a deviant definition of memset).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
silence this warning. ;]
Fixed that obvious bug and added a bit more testing as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130299 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129567 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Luis Felipe Strano Moraes!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129559 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As an extension, generic selection support has been added for all
supported languages. The syntax is the same as for C1X.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129554 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129243 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Dave Zarzycki!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129143 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is a single implementation. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128253 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
just fine, and GCC 4.2 doesn't warn here either.
We added this warning back in 2007 when we were comparing against GCC 4.0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
enumeration type to another in C, classify enumeration constants as if
they had the type of their enclosing enumeration. Fixes
<rdar://problem/9116337>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127514 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
extending the existing support for sizeof and alignof. Original
patch by Guy Benyei.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the call to getSpellingLoc(). On 'aes.c'
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accesses in ?: expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
never can be a real security issue.
Fixes PR 9314.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
code the diagnostic is associated with.
This Stmt* is unused, but we will use it shortly for pruning diagnostics associated
with unreachable code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126286 91177308-0d34-0410-b5e6-96231b3b80d8
|