Use self-init.m for testing. (It used to have a bunch of failing tests
with dynamic inlining turned on.)

llvm-svn: 161012

sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.

llvm-svn: 161008

Previously, we were only checking the origin expressions of inlined calls.
Checkers using the generic postCall and older postObjCMessage callbacks were
ignored. Now that we have CallEventManager, it is much easier to create
a CallEvent generically when exiting an inlined function, which we can then
use for post-call checks.

No test case because we don't (yet) have any checkers that depend on this
behavior (which is why it hadn't been fixed before now).

llvm-svn: 161005

Extend the ',' versus ';' diagnostic for -Wvexing-parse to cover the with-arguments case as well as the no-arguments case.

llvm-svn: 160999

accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.

Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.

llvm-svn: 160998

type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a 
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838

llvm-svn: 160993

- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).

llvm-svn: 160991

llvm-svn: 160989

dispatched methods.

Disabled by default for now.

llvm-svn: 160988

This ensures that it is valid to reference-count any CallEvents, and we
won't accidentally try to reclaim a CallEvent that lives on the stack.
It also hides an ugly switch statement for handling CallExprs!

There should be no functionality change here.

llvm-svn: 160986

While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.

llvm-svn: 160984

This allows us to get around the C++ "virtual constructor" problem
when we'd like to create a CallEvent from an ExplodedNode, an inlined
StackFrameContext, or another CallEvent. The solution has three parts:

- CallEventManager uses a BumpPtrAllocator to allocate CallEvent-sized
  memory blocks. It also keeps a cache of freed CallEvents for reuse.
- CallEvents all have protected copy constructors, along with cloneTo()
  methods that use placement new to copy into CallEventManager-managed
  memory, vtables intact.
- CallEvents owned by CallEventManager are now wrapped in an
  IntrusiveRefCntPtr. Going forwards, it's probably a good idea to create
  ALL CallEvents through the CallEventManager, so that we don't accidentally
  try to reclaim a stack-allocated CallEvent.

All of this machinery is currently unused but will be put into use shortly.

llvm-svn: 160983

command

llvm-svn: 160975

llvm-svn: 160973

llvm-svn: 160972

This makes Clang check that the corresponding argument for "%n" in a
format string is a pointer to int.

llvm-svn: 160966

llvm-svn: 160962

When performing the simplistic overload resolution for single-argument methods,
don't check the best overload for ambiguity with itself when the best overload
doesn't happen to be the first one.

Fixes PR13480.

llvm-svn: 160961

llvm-svn: 160958

llvm-svn: 160947

Provide correct linker command line options on FreeBSD 8 (GNU ld 2.15) and on newer FreeBSD (GNU ld 2.17).

Patch by Dimitry Andric!

llvm-svn: 160931

expressions to have complete return types (or accessible destructors). If the
return type is required to be complete for some other reason (for instance, if
it is needed by overload resolution), then it will still be required to be
complete. This is apparently required in order to parse a MSVC11 header.

llvm-svn: 160924

CF to ARC conversions.

llvm-svn: 160923

llvm-svn: 160908

__bride fixit, as it doesn't matter which cast to
use. // rdar://11923822

llvm-svn: 160906

// rdar://11923822

llvm-svn: 160902

llvm-svn: 160901

are cast to retainable types, only suggest CFBridgingRelease/
CFBridgingRetain and not the __bridge casts.
// rdar://11923822

llvm-svn: 160900

arguments.  Just an optimization, no functional change.

llvm-svn: 160896

llvm-svn: 160895

hex: ) during comment parsing.

Now internal representation of plain text in comment AST does not contain
character references, but the characters themselves.

llvm-svn: 160891

llvm-svn: 160890

Clang's -Wformat fix-its currently suggest using "%zu" for values of
type size_t (in C99 or C++11 mode). However, for a type such as
std::vector<T>::size_type, it does not notice that type is actually
typedeffed to size_t, and instead suggests a format for the underlying
type, such as "%lu" or "%u".

This commit makes the format string fix mechanism walk the typedef chain
so that it notices if the type is size_t, even if that isn't "at the
top".

llvm-svn: 160886

Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.

Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.

llvm-svn: 160885

The __BYTE_ORDER__ predefined macro was added in GCC 4.6:
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/cpp/Common-Predefined-Macros.html

It's used like the following:

 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 ...
 #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 ...
 #else
 #error insane architecture like the pdp-11
 #endif

There's a similar macro, __FLOAT_WORD_ORDER__, but it looks like it
mainly exist to accommodate fairly obscure architectures and ARM's
old FPA instructions, so it doesn't seem nearly as useful.

The tests are updated to check for the correct(at least, based on
clang's current output) value of the macro on each target. So now the
suite will catch bugs like the one fixed in r157626.

llvm-svn: 160879

llvm-svn: 160857

Fix PR13394: Erasing from a vector changes the end of the vector, so make sure we always have the right end.

llvm-svn: 160855

llvm-svn: 160851

llvm-svn: 160850

a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).

EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.

This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.

The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.

Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).

llvm-svn: 160847