don't explode if the offset we get is zero.  This can happen if
you have an empty virtual base class.

While I'm at it, remove an unnecessary block from the IR-generation
of the null-check, mark the eventual GEP as inbounds, and generally
prettify.

llvm-svn: 161100

llvm-svn: 161088

The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.

This also fixes PR13372 as a side-effect.

llvm-svn: 161087

sure to supply an initialization location. Fixes <rdar://problem/11951661>.

llvm-svn: 161084

fails to consider the linkage, which we were already considering.

llvm-svn: 161070

For now this will stay on, but this way it's easy to switch off if we need
to pull back our support for a while.

llvm-svn: 161064

llvm-svn: 161060

While usually we'd use a symbolic region rather than a straight-up Unknown,
we can still generate unknowns via array subscripts with symbolic indexes.
(And if this ever changes in the future, we still shouldn't crash.)

llvm-svn: 161059

llvm-svn: 161058

Warn about using pointers to const-qualified types as arguments to
scanf. Ignore the volatile qualifier when checking if types match.

llvm-svn: 161052

This was causing a crash in our array-to-pointer logic, since the region
was clearly not an array.

PR13440 / <rdar://problem/11977113>

llvm-svn: 161051

code-completion and an Objective-C message send, based on Jordan's
feedback.

llvm-svn: 161049

Clear the FileManager's stat cache in between running
translation units, as the stat cache loaded from a pch
is only valid for one compiler invocation.

llvm-svn: 161047

llvm-svn: 161044

llvm-svn: 161040

llvm-svn: 161038

llvm-svn: 161036

on object pointers and whether pointer arithmetic on object pointers
is supported.  Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.

llvm-svn: 161028

attribute. It is a variation of the x86_64 ABI:

* A struct returned indirectly uses the first register argument to pass the
  pointer.
* Floats, Doubles and structs containing only one of them are not passed in
  registers.
* Other structs are split into registers if they fit on the remaining ones.
  Otherwise they are passed in memory.
* When a struct doesn't fit it still consumes the registers.

llvm-svn: 161022

type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.

Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.

llvm-svn: 161020

llvm-svn: 161019

This removes explicit checks for 'this' and 'self' from
Store::enterStackFrame. It also removes getCXXThisRegion() as a virtual
method on all CallEvents; it's now only implemented in the parts of the
hierarchy where it is relevant. Finally, it removes the option to ask
for the ParmVarDecls attached to the definition of an inlined function,
saving a recomputation of the result of getRuntimeDefinition().

No visible functionality change!

llvm-svn: 161017

This is just a clarification on Fariborz's original patch, per e-mail
discussion. No functionality change.

llvm-svn: 161016

lambda-introducer in Objective-C++11, fall back to treating the tokens
as an Objective-C message send to provide those (more likely)
completions. Fixes <rdar://problem/11980263>.

llvm-svn: 161015

this-adjustment thunk in ARC++.

llvm-svn: 161014

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