- May 03, 2010
-
-
Anders Carlsson authored
llvm-svn: 102889
-
Anders Carlsson authored
llvm-svn: 102888
-
Anders Carlsson authored
llvm-svn: 102887
-
Anders Carlsson authored
llvm-svn: 102886
-
Anders Carlsson authored
llvm-svn: 102885
-
Anders Carlsson authored
llvm-svn: 102884
-
Anders Carlsson authored
llvm-svn: 102883
-
Anders Carlsson authored
llvm-svn: 102882
-
Anders Carlsson authored
llvm-svn: 102881
-
Anders Carlsson authored
llvm-svn: 102880
-
Anders Carlsson authored
Add an enum to CXXConstructExpr so we can determine if the construction expression constructs a non-virtual or virtual base. llvm-svn: 102879
-
- May 02, 2010
-
-
Anders Carlsson authored
llvm-svn: 102871
-
Anders Carlsson authored
llvm-svn: 102870
-
Benjamin Kramer authored
llvm-svn: 102863
-
David Chisnall authored
llvm-svn: 102862
-
- May 01, 2010
-
-
Douglas Gregor authored
assignment operators. Previously, Sema provided type-checking and template instantiation for copy assignment operators, then CodeGen would synthesize the actual body of the copy constructor. Unfortunately, the two were not in sync, and CodeGen might pick a copy-assignment operator that is different from what Sema chose, leading to strange failures, e.g., link-time failures when CodeGen called a copy-assignment operator that was not instantiation, run-time failures when copy-assignment operators were overloaded for const/non-const references and the wrong one was picked, and run-time failures when by-value copy-assignment operators did not have their arguments properly copy-initialized. This implementation synthesizes the implicitly-defined copy assignment operator bodies in Sema, so that the resulting ASTs encode exactly what CodeGen needs to do; there is no longer any special code in CodeGen to synthesize copy-assignment operators. The synthesis of the body is relatively simple, and we generate one of three different kinds of copy statements for each base or member: - For a class subobject, call the appropriate copy-assignment operator, after overload resolution has determined what that is. - For an array of scalar types or an array of class types that have trivial copy assignment operators, construct a call to __builtin_memcpy. - For an array of class types with non-trivial copy assignment operators, synthesize a (possibly nested!) for loop whose inner statement calls the copy constructor. - For a scalar type, use built-in assignment. This patch fixes at least a few tests cases in Boost.Spirit that were failing because CodeGen picked the wrong copy-assignment operator (leading to link-time failures), and I suspect a number of undiagnosed problems will also go away with this change. Some of the diagnostics we had previously have gotten worse with this change, since we're going through generic code for our type-checking. I will improve this in a subsequent patch. llvm-svn: 102853
-
Anders Carlsson authored
llvm-svn: 102849
-
Anders Carlsson authored
llvm-svn: 102848
-
Douglas Gregor authored
llvm-svn: 102847
-
Anders Carlsson authored
llvm-svn: 102846
-
Anders Carlsson authored
llvm-svn: 102845
-
Anders Carlsson authored
llvm-svn: 102842
-
Douglas Gregor authored
information required to implicitly define a C++ special member function. Use it rather than explicitly setting CurContext on entry and exit, which is fragile. Use this RAII object for the implicitly-defined default constructor, copy constructor, copy assignment operator, and destructor. llvm-svn: 102840
-
David Chisnall authored
llvm-svn: 102839
-
David Chisnall authored
llvm-svn: 102837
-
David Chisnall authored
Used this in CGObjCGNU to attach metadata about message sends to permit speculative inlining. llvm-svn: 102833
-
John McCall authored
already knows what context it's looking in. Just pass that context in instead of (questionably) recalculating it. llvm-svn: 102818
-
Ted Kremenek authored
more resilient to bad code. llvm-svn: 102793
-
- Apr 30, 2010
-
-
Ted Kremenek authored
fatal error has occurred. llvm-svn: 102778
-
Douglas Gregor authored
parameter with pointer-to-member type, we may have to perform a qualification conversion, since the pointee type of the parameter might be more qualified than the pointee type of the argument we form from the declaration. Fixes PR6986. llvm-svn: 102777
-
John McCall authored
access. Fixes an assertion. Fixes rdar://problem/7927811. Too lazy to reduce a test case. llvm-svn: 102776
-
Douglas Gregor authored
constant expression in C. llvm-svn: 102762
-
Anders Carlsson authored
llvm-svn: 102747
-
Douglas Gregor authored
of the mapping from local declarations to their instantiated counterparts during template instantiation. Previously, we tried to do some unholy merging of local instantiation scopes that involved storing a single hash table along with an "undo" list on the side... which was ugly, and never handled function parameters properly. Now, we just keep separate hash tables for each local instantiation scope, and "combining" two scopes means that we'll look in each of the combined hash tables. The combined scope stack is rarely deep, and this makes it easy to avoid the "undo" issues we were hitting. Also, I've simplified the logic for function parameters: if we're declaring a function and we need the function parameters to live longer, we just push them back into the local instantiation scope where we need them. Fixes PR6990. llvm-svn: 102732
-
David Chisnall authored
llvm-svn: 102711
-
Abramo Bagnara authored
Add calling convention related attributes to related declaration. Mark attributes invalid on type related checking so to add them to declarations only when everything is ok. llvm-svn: 102710
-
Abramo Bagnara authored
llvm-svn: 102705
-
John McCall authored
if *none* of the successors of the call expression is the exit block. This matters when a call of bool type is the condition of (say) a while loop in a function with no statements after the loop. This *can* happen in C, but it's much more common in C++ because of overloaded operators. Suppresses some substantial number of spurious -Wmissing-noreturn warnings. llvm-svn: 102696
-
Douglas Gregor authored
llvm-svn: 102695
-
Douglas Gregor authored
specializations, which keeps track of the order in which they were originally declared. We use this number so that we can always walk the list of partial specializations in a predictable order during matching or template instantiation. This also fixes a failure in Boost.Proto, where SourceManager::isBeforeInTranslationUnit was behaving poorly in inconsistent ways. llvm-svn: 102693
-