of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
llvm-svn: 114225
This mainly prevents failures and/or crashes when multiple processes try to read/write the same PCH file. (rdar://8392711&8294781); suggestion & review by Daniel!
llvm-svn: 114187
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
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
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
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
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
Bill Wendling