- Added checks for static local variables, self assigned parameters, and truncating/extending self assignments
- Removed command line option (now default with --analyze)
- Updated test cases to pass with idempotent operation warnings
llvm-svn: 108550
expression such as the "foo" in "this->blah.foo<1, 2>", and we can't
look into the type of "this->blah" (e.g., because it is dependent),
look into the local scope of a template of the same name. Fixes
<rdar://problem/8198511>.
llvm-svn: 108531
handling the parsing of scanf format strings and hooking the checking into Sema.
Most of this checking logic piggybacks on what was already there for checking printf format
strings, but the checking logic has been refactored to support both.
What is left to be done is to support argument type checking in format strings and of course
fix the usual tail of bugs that will follow.
llvm-svn: 108500
represent builtins that have the "scanf" attribution (via the format attribute) just
like we do with printf functions. Follow-up work is needed to add similar support
for fscanf et al.
This is to support format-string checking for scanf functions.
llvm-svn: 108499
- This issue here is that /usr/include/Blocks.h wants to define some of the
block runtime globals as weak, depending on the target. This doesn't work in
Clang because we aren't using the AST decl for these globals.
- The fix is a pretty gross hack which just watches all the decls for the
specific blocks globals we need to know about; if we see one we use it,
otherwise we use the hand coded type.
In time, I would like to clean this up by changing IRgen to ask Sema/AST for
the decl, which would then be lazily loaded from the builtin table if
necessary. This could be used in a whole host of places in IRgen and would
get rid of a lot of grotty hand coding of LLVM IR; however, we need some
extra Sema support for this as well as support for builtin global variables.
llvm-svn: 108482
parser is looking at a declaration or an expression, use a '=' to
conclude that we are parsing a declaration.
This is wrong. However, our previous approach of finding a comma after
the '=' is also wrong, because the ',' could be part of a
template-argument-list. So, for now we're going to use the same wrong
heuristic as GCC and Visual C++, because less real-world code is
likely to be broken this way. I've opened PR7655 to keep track of our
wrongness; note also the XFAIL'd test.
Fixes <rdar://problem/8193163>.
llvm-svn: 108459
that involve binding a reference to a pure rvalue temporary (e.g., not
a class temporary), by creating a new temporary and copying the result
there. Fixes PR6024.
llvm-svn: 108431
whether to use objc_msgSend_fpret; the choice is target dependent, not Obj-C ABI
dependent.
- <rdar://problem/8139758> arm objc _objc_msgSend_fpret bug
llvm-svn: 108379
definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.
llvm-svn: 108372
- TSTs whose template is a template template parameter already work
- we don't provide an imaginary type, so we can't mangle one
- we don't need a generic FIXME for vendor type qualifiers
llvm-svn: 108317
reinterpret_casts (possibly indirectly via C-style/functional casts)
on values, e.g.,
int i;
reinterpret_cast<short&>(i);
The IR generated for this is essentially the same as for
*reinterpret_cast<short*>(&i).
Fixes PR6437, PR7593, and PR7344.
llvm-svn: 108294
mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.
Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this; for now we have some awkward code
duplication.
Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.
llvm-svn: 108270
t2.c:2:12: warning: use of logical && with constant operand; switch to bitwise &
or remove constant [-Wlogical-bitwise-confusion]
return x && 4;
^ ~
wording improvement suggestions are welcome.
llvm-svn: 108260
(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary.
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
When loading the PCH, IdentifierInfos that are associated with pragmas cause declarations that use these identifiers to be deserialized (e.g. the "clang" pragma causes the "clang" namespace to be loaded).
We can avoid this if we just use StringRefs for the pragmas.
As a bonus, since we don't have to create and pass IdentifierInfos, the pragma interfaces get a bit more simplified.
llvm-svn: 108237
effect warning" by printing the qualifiers we saw and correctly
pluralizing the message, e.g.,
test/SemaCXX/conditional-expr.cpp:295:3: warning: 'const volatile' type
qualifiers on return type have no effect
const volatile Enum g2() {
^~~~~ ~~~~~~~~
llvm-svn: 108236
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
at -O0. The only change from the previous patch is that we don't try
to generate virtual method thunks for an available_externally
function.
llvm-svn: 108230
class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.
llvm-svn: 108217
-O0, since we won't be using the definitions for anything anyway. For
lib/System/Path.o when built in Debug+Asserts mode, this leads to a 4%
improvement in compile time (and suppresses 440 function bodies).
<rdar://problem/7987644>
llvm-svn: 108156
around by exempting enums from the check, but this doesn't handle a lot of
cases. A better approach is to directly check if the operator comes from
a macro expansion.
I've removed a reference to the rdar that originally led to the enum
suppression when removing it's overly contrived test case. Let me know if that
number or a more reasilistic test case involving enums is still needed.
llvm-svn: 108128
In the case of backtracking, the cached token lexer will be the only
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.
This fixes PR7072.
llvm-svn: 108124
a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.
Also, avoid skipping randomly after a declaration if a
semicolon is missing. Before we'd get:
t.c:3:1: error: expected function body after function declarator
void bar();
^
Now we get:
t.c:1:11: error: invalid token after top level declarator
void foo()
^
;
llvm-svn: 108105
default arguments to template parameters don't have a DeclContext when
instantiated, and so we can't detect that we're in an instantiation context as
opposed to the definition context. However, it fixes the more commonly-occuring
cases in TMP code that use devolve to this type of tautology after
substitution.
llvm-svn: 108044
for code like this:
template<template<typename T> class U> class V {};
The problem is that the DeclPrinter assumed all TemplateDecls
have a getTemplatedClass(), but template template params don't
(so we got a NULL dereference). The solution is to detect if
we're a template template param, and construct the template
class name ('class U') specially in this case.
OKed by dgregor and chandlerc
llvm-svn: 108007
expected value type. This is necessary as the builtin is internally represented
as only operating on integral types.
Also, add a FIXME to add support for floating point value types.
llvm-svn: 108002
selector of an Objective-C method declaration, e.g., given
- (int)first:(int)x second:(int)y;
this code completion point triggers at the location of "second". It
will provide completions that fill out the method declaration for any
known method, anywhere in the translation unit.
llvm-svn: 107929
unknown attributes that we discard. Add a diagnostic group for unknown
attribute warnings to allow turning these off when we don't care. Also
consolidates the tests for this case.
llvm-svn: 107864
was not producing a memcpy with the right address
spaces because of two places in it doing casts of
the arguments to i8, one of which that didn't
preserve the address space.
There is also an optimizer bug here.
llvm-svn: 107842
typedefs won't have the same canonical declaration (since they are
distinct), so we need to check for this case specifically. Fixes
<rdar://problem/8018262>.
llvm-svn: 107833
CXXConstructExpr/CXXTemporaryObjectExpr/CXXNewExpr as
appropriate. Fixes PR7556, and provides a slide codegen improvement
when copy-initializing a POD class type from a value-initialized
temporary. Previously, we weren't eliding the copy.
llvm-svn: 107827
Benjamin Kramer