reparses an already-parsed translation unit. At the moment it's just a
convenience function, but we hope to use it for performance
optimizations.
llvm-svn: 108756
A ParmVarDecl instantiated from a FunctionProtoType may have Record as DeclContext,
in which case isStaticDataMember() will erroneously return true.
llvm-svn: 108692
taking it in pieces.
- Fixes a problem where the Clang executable path was not initialized properly
on Win32, because sys::Path::getBasename() doesn't do what I always think it
does. Imagine that, a sys::Path interface that is confusing!
llvm-svn: 108667
The rationale is that we are copying the entire definition including
parameter names which may differ between the declaration and the
definition.
This is particularly important if any parameters are unnamed in the
declaration, as a DeclRef to an unnamed ParmVarDecl would cause the
pretty printer to produce invalid output.
llvm-svn: 108643
their call expressions synthetically have the "deduced" types based on their
first argument. We only insert conversions in the AST for arguments whose
values require conversion to match the value type expected. This keeps PR7600
closed by maintaining the return type, but avoids assertions due to unexpected
implicit casts making the type unsigned (test case added from Daniel).
The magic is moved into the codegen for the atomic builtin which inserts the
casts as needed at the IR level to raise the type to an integer suitable for
the LLVM intrinsic. This shouldn't cause any real change in functionality, but
now we can make the builtin be more truly polymorphic.
llvm-svn: 108638
- 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
This has 2 (slight) advantages:
-Make explicit at getBody()'s callsite that we expect/handle only CompoundStmt and not CXXTryStmt.
-Better tracking of Decl::getBody()'s callsites.
llvm-svn: 107771
emit metadata associating allocas and global values with a Decl*. This feature
is controlled by an option that (intentionally) cannot be enabled on the command
line.
To use this feature, simply set
CodeGenOptions.EmitDeclMetadata = true;
and then interpret the completely underspecified metadata. :)
llvm-svn: 107739
Example:
{
int a = 1;
int b = 5;
int c = b / a; // a is 1 on all paths
}
- New IdempotentOperationChecker class
- Moved recursive Stmt functions in r107675 to IdempotentOperationChecker
- Minor refactoring of SVal to allow checking for any integer
- Added command line option for check
- Added basic test cases
llvm-svn: 107706
declarations when implicitly declaring the default constructor, copy
constructor, destructor, and copy-assignment operators of a
class. Argiris fixed the underlying problem in r107596.
llvm-svn: 107681
self-host. Hopefully these results hold up on different platforms.
I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions. Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.
Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former. Remove the need to track which cleanup scope a block is associated
with.
Document a lot of previously poorly-understood (by me, at least) behavior.
The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work. Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however. The HH is an unfortunate requirement of LLVM's EH IR.
llvm-svn: 107631
alloca for an argument. Make sure the argument gets the proper
decl alignment, which may be different than the type alignment.
This fixes PR7567
llvm-svn: 107627
Some of the invariant checks for creating Record/Enum types don't hold true during PCH reading.
Introduce more suitable ASTContext::getRecordType() and getEnumType().
llvm-svn: 107598
Before this commit, visible decls added before deserialization were ignored.
This was not an issue since name lookup (that usually comes before the addition) forces deserialization
but it is an issue for lazily declared class implicit members.
We can use a PCH'ed <string> now.
llvm-svn: 107596
Currently, adding it to visible decls of a PCH'ed translation unit has no effect because
adding visible decls before deserialization has no effect (the decls won't be visible).
This will be fixed in a future commit; then it will force deserialization of visible decls, so avoid pointlessly installing it.
llvm-svn: 107595
Also adds a getKnownValue() method to SValuator, which gets the integer value of an SVal if it is known to only have one possible value. There are more places in the code that could be using this, but in general we want to be dealing entirely in SVals, so its usefulness is limited.
The only visible functionality change is that extents are now honored for any DeclRegion, such as fields and Objective-C ivars, rather than just variables. This shows up in bounds-checking and cast-size-checking.
llvm-svn: 107577
Stuart Hastings