| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 104237
|
| |
|
|
|
|
| |
be turned into a setter call (fixes radar 8008649).
llvm-svn: 104235
|
| |
|
|
| |
llvm-svn: 104230
|
| |
|
|
| |
llvm-svn: 104229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
particular issue was the cause of the Boost.Interprocess failures, and
in general will lead to horrendous, hard-to-diagnose miscompiles. The
assertion itself has survives self-host and a full Boost build, so we
are close to eradicating this problem in C++.
Note that the assertion is *not* turned on for Objective-C++, where we
still have problems with introducing memcpy's of non-POD class
types. That part of the assertion will go away as soon as we fix the
known issues in Objective-C++.
llvm-svn: 104227
|
| |
|
|
| |
llvm-svn: 104226
|
| |
|
|
|
|
| |
returning non-pointer-sized things were generating invalid IR inside @try blocks.
llvm-svn: 104222
|
| |
|
|
|
|
| |
getFullSourceRange -> getSourceRange for TypeLoc.
llvm-svn: 104220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
subobject. Previously, we could only properly bind to a base class
subobject while extending the lifetime of the complete object (of a
derived type); for non-static data member subobjects, we could memcpy
(!) the result and bind to that, which is rather broken.
Now, we pull apart the expression that we're binding to, to figure out
which subobject we're accessing, then construct the temporary object
(adding a destruction if needed) and, finally, dig out the subobject
we actually meant to access.
This fixes yet another instance where we were memcpy'ing rather than
doing the right thing. However, note the FIXME in references.cpp:
there's more work to be done for binding to subobjects, since the AST
is incorrectly modeling some member accesses in base classes as
lvalues when they are really rvalues.
llvm-svn: 104219
|
| |
|
|
| |
llvm-svn: 104218
|
| |
|
|
|
|
| |
<rdar://problem/7995494>.
llvm-svn: 104217
|
| |
|
|
|
|
|
|
|
| |
class type (that uses a return slot), pass the return slot to the
callee directly rather than allocating new storage and trying to copy
the object. This appears to have been the cause of the remaining two
Boost.Interprocess failures.
llvm-svn: 104215
|
| |
|
|
| |
llvm-svn: 104207
|
| |
|
|
|
|
|
|
|
|
| |
instance variables:
- Use isRecordType() rather than isa<RecordType>(), so that we see
through typedefs in ivar types.
- Mark the destructor as referenced
- Perform C++ access control on the destructor
llvm-svn: 104206
|
| |
|
|
|
|
| |
<rdar://problem/8007063>.
llvm-svn: 104205
|
| |
|
|
|
|
| |
(the codegen works here, too, but that's annoying to test without execution)
llvm-svn: 104202
|
| |
|
|
|
|
| |
c++'03 code and variadic support "needs work".
llvm-svn: 104195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
smallvector
instead of new[]'d. This greatly reduces the number of new[]'s, and guess what,
they were all leaked.
This adds a fixme in this hunk:
unsigned NumPackArgs = NumFlatArgs - PackBeginIndex;
+ // FIXME: NumPackArgs shouldn't be negative here???
if (NumPackArgs)
- PackArgs = &FlatArgs[PackBeginIndex];
+ PackArgs = FlatArgs.data()+PackBeginIndex;
where test/SemaTemplate/variadic-class-template-2.cpp is accessing the vector
out of range and NumPackArgs is negative. I assume variadic template args are
completely hosed.
llvm-svn: 104194
|
| |
|
|
|
|
|
| |
be a copy constructor (since it isn't one semantically)
and fix the ownership bits it sets to be correct!
llvm-svn: 104192
|
| |
|
|
|
|
|
| |
"structure" arg lists, the first step to fixing some massive
memory leaks.
llvm-svn: 104191
|
| |
|
|
|
|
| |
suggested modification.
llvm-svn: 104188
|
| |
|
|
|
|
|
|
|
|
| |
create a temporary copy of both the "true" and "false" results. Fixes
the Boost.Interprocess failures.
Daniel did all the hard work of tracking down the issue, I get to type
up the trivial fix for this horrible miscompile.
llvm-svn: 104184
|
| |
|
|
| |
llvm-svn: 104169
|
| |
|
|
|
|
| |
object variables and functions returning such objects.
llvm-svn: 104168
|
| |
|
|
|
|
|
| |
occuring on..." which breaks some Objective-C code. Working on getting a test
case...
llvm-svn: 104150
|
| |
|
|
| |
llvm-svn: 104140
|
| |
|
|
|
|
|
| |
some seriously non-linear performance with deeply nested template
instantiations, as shown in PR6998.
llvm-svn: 104139
|
| |
|
|
| |
llvm-svn: 104135
|
| |
|
|
| |
llvm-svn: 104121
|
| |
|
|
| |
llvm-svn: 104118
|
| |
|
|
|
|
|
|
|
|
|
| |
template names. We were completely missing naming classes for many unqualified
lookups, but this didn't trigger code paths that need it. This removes part of
an optimization that re-uses the template name lookup done by the parser to
determine if explicit template arguments actually form a template-id.
Unfortunately the technique for avoiding the duplicate lookup lost needed data
such as the class context in which the lookup succeeded.
llvm-svn: 104117
|
| |
|
|
|
|
|
| |
way regardless of whether some overloaded operator functions were
found by name lookup within the template. Fixes PR6851.
llvm-svn: 104107
|
| |
|
|
| |
llvm-svn: 104106
|
| |
|
|
| |
llvm-svn: 104105
|
| |
|
|
|
|
|
|
|
| |
the same .cpp file as provided the definitions referenced these functions,
hiding the issue. However, they are clearly no longer inline. Let me know if
there is a reason to move their definitions to the header and make them truly
inline.
llvm-svn: 104104
|
| |
|
|
|
|
| |
welcome for one.
llvm-svn: 104101
|
| |
|
|
|
|
|
| |
gc attributes to be inline with Objective-C
(for radar 7925141).
llvm-svn: 104084
|
| |
|
|
|
|
| |
expressions in attributes, pragmas.
llvm-svn: 104083
|
| |
|
|
|
|
|
|
|
|
| |
involves extending implicit conversion sequences to model vector
conversions and vector splats, along with teaching the C++ conditional
operator-checking code about vector types.
Fixes <rdar://problem/7983501>.
llvm-svn: 104081
|
| |
|
|
|
|
|
|
|
|
| |
of a current
design limitation in how we handle Objective-C class extensions. This was causing the CursorVisitor
to essentially visit an @property twice (once in the @interface, the other in the class extension).
Fixes <rdar://problem/7410145>.
llvm-svn: 104055
|
| |
|
|
| |
llvm-svn: 104026
|
| |
|
|
|
|
| |
that test case is a bit weird and I'd like to investigate further before closing that bug.
llvm-svn: 104025
|
| |
|
|
|
|
|
|
|
| |
non-function-local declarations with names similar to what the user
typed. For example, this allows us to correct 'supper' to 'super' in
an Objective-C message send, even though the C function 'isupper' has
the same edit distance.
llvm-svn: 104023
|
| |
|
|
|
|
|
|
|
| |
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
llvm-svn: 104022
|
| |
|
|
| |
llvm-svn: 104019
|
| |
|
|
|
|
|
| |
Also rename ABSTRACT to ABSTRACT_STMT, in keeping with the other .def
files
llvm-svn: 104017
|
| |
|
|
|
|
|
| |
for Visual Studio 2010. It also adds a registry search
for the Express edition,", from Steven Watanabe!
llvm-svn: 104015
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert much of the implementation of C++98/03 [temp.friend]p5 in
r103943 and its follow-ons r103948 and r103952. While our
implementation was technically correct, other compilers don't seem to
implement this paragraph (which forces the instantiation of friend
functions defined in a class template when a class template
specialization is instantiated), and doing so broke a bunch of Boost
libraries.
Since this behavior has changed in C++0x (which instantiates the
friend function definitions when they are used), we're going to skip
the nowhere-implemented C++98/03 semantics and go straight to the
C++0x semantics.
This commit is a band-aid to get Boost up and running again. It
doesn't really fix PR6952 (which this commit un-fixes), but it does
deal with the way Boost.Units abuses this particular paragraph.
llvm-svn: 104014
|
| |
|
|
| |
llvm-svn: 104013
|
| |
|
|
|
|
| |
this is a step in the right direction.
llvm-svn: 104012
|