- Mar 31, 2009
-
-
Daniel Dunbar authored
- Current return-arguments-32 status: 15/1000 failures llvm-svn: 68132
-
Douglas Gregor authored
template template parameters and dependent template names. For example, the oft-mentioned typename MetaFun::template apply<T1, T2>::type can now be instantiated, with the appropriate name lookup for "apply". llvm-svn: 68128
-
Fariborz Jahanian authored
llvm-svn: 68122
-
Daniel Dunbar authored
- Always pass -triple to clang-cc (-arch will be removed). - clang-cc doesn't play guess work with the target triple anymore. llvm-svn: 68119
-
Steve Naroff authored
llvm-svn: 68117
-
Steve Naroff authored
llvm-svn: 68107
-
Chris Lattner authored
In a case like: @class foo; foo *P; addRecordToClass was making an empty shadow struct for the foo interface and completing it. Later when an: @interface foo ... @endif foo *Q; was seen, ASTContext::addRecordToClass would think that foo was already laid out and not lay out the definition. This fixes it to create a forward declared struct the first time around, then complete it when the definition is seen. Note that this causes two tests to regress, because something is trying to get the size of the forward declared structs returned by this. Previously, this would end up getting a size of zero but now it properly dies. I'm not sure what the right solution is for this, so I xfailed the tests. Fariborz, please take a look at this. The testcase in rdar://6676794 now gets farther, but dies later because the objc ivar is not assigned a field number. As an aside, I really don't like the fact that the objc front-end is creating shadow C structs for ObjC types. This seems like an implementation detail of the code generator that could be fixed by better factoring of the extant code. llvm-svn: 68106
-
Chris Lattner authored
disable this feature for now, to err on the side of rejecting instead of sometimes crashing. rdar://6326239 llvm-svn: 68088
-
Anders Carlsson authored
llvm-svn: 68086
-
Ted Kremenek authored
llvm-svn: 68084
-
Douglas Gregor authored
within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
-
Fariborz Jahanian authored
llvm-svn: 68077
-
Steve Naroff authored
Implement UCN support for C string literals (C99 6.4.3) and add some very basic tests. Chris Goller has graciously offered to write some test to help validate UCN support. From a front-end perspective, I believe this code should work for ObjC @-strings. At the moment, I believe we need to tweak the code generation for @-strings (which doesn't appear to handle them). Will be investigating. llvm-svn: 68076
-
- Mar 30, 2009
-
-
Ted Kremenek authored
handles declarations with multiple variables. llvm-svn: 68046
-
Daniel Dunbar authored
- <rdar://problem/6726511> [driver] clang does not have -msoft-float hooked up. llvm-svn: 68044
-
Daniel Dunbar authored
llvm-svn: 68042
-
Daniel Dunbar authored
llvm-svn: 68029
-
Daniel Dunbar authored
- Not particularly elegant, but my hand is forced by gcc. Also, tweak -ccc-print-bindings output. llvm-svn: 68027
-
Daniel Dunbar authored
- Rip out various bits of logic from clang-cc's dependency file gen, force driver to provide instead. - -MD output now goes to proper location <rdar://problem/6723948> clang -MD puts dep file in /tmp with wrong name - -M and -MM still don't work correctly. llvm-svn: 68022
-
Daniel Dunbar authored
tools, and enable them. llvm-svn: 68019
-
- Mar 29, 2009
-
-
Chris Lattner authored
into ParseForStatement. Merge two tests into one. llvm-svn: 68010
-
Chris Lattner authored
into ParseSimpleDeclaration, and improve a diagnostic. llvm-svn: 68009
-
Sebastian Redl authored
Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me. llvm-svn: 67999
-
Anders Carlsson authored
More improvements to namespace aliases. We now support everything except aliases in using directives. llvm-svn: 67966
-
Anders Carlsson authored
llvm-svn: 67964
-
- Mar 28, 2009
-
-
Ted Kremenek authored
<rdar://problem/6732151>. llvm-svn: 67954
-
Anders Carlsson authored
llvm-svn: 67932
-
Anders Carlsson authored
llvm-svn: 67925
-
Anders Carlsson authored
llvm-svn: 67921
-
Anders Carlsson authored
SemaCXX//overload-member-call.cpp SemaCXX//overloaded-operator.cpp SemaTemplate//instantiate-method.cpp llvm-svn: 67912
-
Anders Carlsson authored
llvm-svn: 67908
-
Eli Friedman authored
types don't get generated when blocks aren't used. llvm-svn: 67898
-
Eli Friedman authored
llvm-svn: 67897
-
Eli Friedman authored
llvm-svn: 67895
-
Eli Friedman authored
LHS type and the computation result type; this encodes information into the AST which is otherwise non-obvious. Fix Sema to always come up with the right answer for both of these types. Fix IRGen and the analyzer to account for these changes. This fixes PR2601. The approach is inspired by PR2601 comment 2. Note that this changes real *= complex in CodeGen from a silent miscompilation to an explicit error. I'm not really sure that the analyzer changes are correct, or how to test them... someone more familiar with the analyzer should check those changes. llvm-svn: 67889
-
Anders Carlsson authored
llvm-svn: 67887
-
Douglas Gregor authored
syntax into extension warnings, and provide code-modification hints showing how to fix the problem. llvm-svn: 67885
-
rdar://problem/6724396Douglas Gregor authored
GNU-style array designators, causing us to emit broken initializers. llvm-svn: 67878
-
Douglas Gregor authored
instantiation for C++ typename-specifiers such as typename T::type The parsing of typename-specifiers is relatively easy thanks to annotation tokens. When we see the "typename", we parse the typename-specifier and produce a typename annotation token. There are only a few places where we need to handle this. We currently parse the typename-specifier form that terminates in an identifier, but not the simple-template-id form, e.g., typename T::template apply<U, V> Parsing of nested-name-specifiers has a similar problem, since at this point we don't have any representation of a class template specialization whose template-name is unknown. Semantic analysis is only partially complete, with some support for template instantiation that works for simple examples. llvm-svn: 67875
-
- Mar 27, 2009
-
-
Sebastian Redl authored
llvm-svn: 67870
-