the bases are completely initialized.  This won't work --- base
initializer expressions can rely on the vtables having been set up.
Check for uses of 'this' in the initializers and force a vtable
initialization if found.

This might not be good enough;  we might need to extend this to handle
the possibility of arbitrary code finding an external reference to this
(not yet completely-constructed!) object and accessing through it,
in which case we'll probably find ourselves doing a lot more unnecessary
stores.

llvm-svn: 114153

llvm-svn: 114149

llvm-svn: 114147

the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.

llvm-svn: 114146

the cleanup might not be dominated by the allocation code.
In this case, we have to store aside all the delete arguments
in case we need them later.  There's room for optimization here
in cases where we end up not actually needing the cleanup in
different branches (or being able to pop it after the
initialization code).

Also make sure we only call this operator delete along the path
where we actually allocated something.

Fixes rdar://problem/8439196.

llvm-svn: 114145

-lstdc++. This is the best gross solution for a gross problem.

This issue is that historically, GCC has add -L options to its internally
library directories. This has allowed users and platforms to end up depending on
the layout of GCC's internal library directories.

We want to correct this mistake by eliminating that -L, but this means that
existing libraries which are in the GCC lib dir won't be found. We are going to
handle this by treating those -l names as "reserved", and requiring toolchains
to know how to add the right full path to the reserved library.

The immediately side effect of this is that users trying to use -L to find their
own -lstdc++ will need to start using -nostdlib (which is a good idea
anyway). Another side effect is that -stdlib=libc++ -lstdc++ will now do the
"right" thing, for curious definitions of right.

llvm-svn: 114144

llvm-svn: 114142

llvm-svn: 114138

llvm-svn: 114137

prototype scope, temporarily set the context of the enumeration
declaration to the translation unit. We do the same thing for
parameters, until we have an actual function declaration on which to
hang them. Fixes <rdar://problem/8435682>.

There is more work to do in this area, since we have existing bugs
with tags being declared/defined in function parameter lists. This fix
is correct, and we'll end up extending it when we deal with those
existing bugs.

llvm-svn: 114135

them with a smaller alignment than the rest of codegen expects.

llvm-svn: 114115

reference.

llvm-svn: 114114

with a non-default-stack-ABI-alignment (of 16).
 - This fixes the ABI convenient, but breaks codegen since we now have
   underaligned arguments. Marginal improvement overall though, and will be
   fixed in next commit.

llvm-svn: 114113

Darwin. Checked vs the handiest Linux llvm-gcc I had around, someone on Linux is
welcome to investigate more.

llvm-svn: 114112

warning to handle multiple enumerators with one warning.

llvm-svn: 114093

llvm-svn: 114085

doesn't add any value. Instead, we'll just take the first method with
that selector that we find and create a completion for it.

llvm-svn: 114082

sure to visit the protocols of protocols.

llvm-svn: 114079

missing the opening bracket '[', e.g.,

  NSArray <CC>

at function scope. Previously, we would only give trivial completions
(const, volatile, etc.), because we're in a "declaration name"
scope. Now, we also provide completions for class methods of NSArray,
e.g.,

  alloc

Note that we already had support for this after the first argument,
e.g.,

  NSArray method:x <CC>

would get code completion for class methods of NSArray whose selector
starts with "method:". This was already present because we recover
as if NSArray method:x were a class message send missing the opening
bracket (which was committed in r114057).

llvm-svn: 114078

derive from temporaries of the same type.  Black-list member expressions
as well.

llvm-svn: 114071

translation units that don't catch ObjC types.  rdar://problem/8434851

llvm-svn: 114070

Refactored BugReporter to refer to EndNode as ErrorNode. We currently make the assumption that EndNode == ErrorNode, but upcoming changes will break this.

llvm-svn: 114065

llvm-svn: 114062

llvm-svn: 114061

Prospective fix for broken commit in r114045.

llvm-svn: 114060

sends. These are far trickier than instance messages, because we
typically have something like

  NSArray alloc]

where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).

llvm-svn: 114057

and discussions with Ted and Jordy.

llvm-svn: 114056

Fixes <rdar://problem/8436021>.

llvm-svn: 114049

AggValueSlot slot.

llvm-svn: 114045

are expanded from macros (and if so, omit the warning).  Previously we were just looking at the
location of the binary expression.

Fixes <rdar://problem/8435950>.

llvm-svn: 114044

narrow, almost useless case where we're inside a parenthesized
expression, e.g.,

  (NSArray alloc])

The solution to the general case still eludes me.

llvm-svn: 114039

llvm-svn: 114019

While handling change of file, check if _current_ file is already seen or not. If current file is seen then it indicates that end of previous file's lexical scope.
This fixes radar 8396182.

llvm-svn: 114018

llvm-svn: 114014

from certain GCC's. Patch by Neil Vachharajani!

llvm-svn: 113995

'[' is missing. Prior commits improving recovery also improved code
completion beyond the first selector, e.g., at or after the "to" in

  calculator add:x to:y

but not after "calculator". We now provide the same completions for

  calculator <CC>

that we would for

  [calculator <CC>

if "calculator" is an expression whose type is something that can
receive Objective-C messages.

This code completion works for instance and super message sends, but not
class message sends.

llvm-svn: 113976

abi for clang's objective-c compilations.
(radar 8353555).

llvm-svn: 113974

  super method:arg]

will now recover nicely and insert the '[' before 'super'.

llvm-svn: 113971

  a getFoo]

llvm-svn: 113969

part of parser recovery. For example, given:

  a method1:arg];

we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:

fixit-objc-message.m:17:3: error: missing '[' at start of message
      send expression
  a method1:arg];
  ^
  [

The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.

llvm-svn: 113968