- Jun 27, 2013
-
-
Eli Friedman authored
Armed with a much better understanding of what TemplateSpecializationTypeLoc::initializeArgLocs actually does, I now understand that it's fine to just use an empty TemplateArgumentLocInfo for Integral, Declaration, and NullPtr TemplateArguments. Fixes PR14281. (The testcases are actually derived from libcxx_test in deduction-crash.cpp because the original testcase was impossible to reduce.) llvm-svn: 185038
-
- Jun 21, 2013
-
-
Matt Beaumont-Gay authored
Fixes PR16292. llvm-svn: 184581
-
- Jun 20, 2013
-
-
Eli Friedman authored
llvm-svn: 184465
-
Eli Friedman authored
llvm-svn: 184393
-
- Jun 13, 2013
-
-
Richard Smith authored
not actually talking about a default constructor. llvm-svn: 183885
-
Richard Smith authored
Don't suggest putting 'operator new' or 'operator delete' in a namespace to fix a two-phase lookup issue. That's not permitted. llvm-svn: 183874
-
- Jun 11, 2013
-
-
David Majnemer authored
DR61 affirms that expressions containing unresolved member access should be disallowed when performing "address of" operations. llvm-svn: 183723
-
David Majnemer authored
Disallow the existence of a declaration of a member class that isn't a forward declaration before it's definition. llvm-svn: 183722
-
- Jun 08, 2013
-
-
Faisal Vali authored
Fix the parser's updating of the template depth when parsing local templates and late-parsed templates. This is a slight tweak of r180708; It avoids incrementing depth when non-template local classes nested within member templates of local classes are encountered. This patch was LGTM'd by Doug http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130506/079656.html and passed the regression tests that normally pass (i.e. excluding many Module and Index tests on Windows that fail regardless) llvm-svn: 183620
-
Faisal Vali authored
I ran clang-format on my patch but it seemed to have wreaked havoc with new lines - might have to do with using it on windows :( will resubmit once i've cleaned this issue up. sorry. llvm-svn: 183619
-
Faisal Vali authored
Fix the parser's updating of the template depth when parsing local templates and late-parsed templates. This is a slight tweak of r180708; It avoids incrementing depth when non-template local classes nested within member templates of local classes are encountered. This patch was LGTM'd by Doug http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130506/079656.html and passed the regression tests that normally pass (i.e. excluding many Module and Index tests on Windows that fail regardless) llvm-svn: 183618
-
- Jun 06, 2013
-
-
Anna Zaks authored
When processing ArrayToPointerDecay, we expect the array to be a location, not a LazyCompoundVal. Special case the rvalue arrays by using a location to represent them. This case is handled similarly elsewhere in the code. Fixes PR16206. llvm-svn: 183359
-
- Jun 04, 2013
-
-
David Blaikie authored
Still missing cases for templates, but this is a step in the right direction. Also omits suggestions that would be ambiguous (eg: void func(int = 0); + void func(float = 0); func;) llvm-svn: 183173
-
- May 22, 2013
-
-
Richard Smith authored
operand of a unary address-of expression, not for *all* expressions! llvm-svn: 182436
-
- May 16, 2013
-
-
Richard Trieu authored
crash on an explicit specialization of a member function in a class scope. llvm-svn: 181971
-
- May 04, 2013
-
-
- May 03, 2013
-
-
Douglas Gregor authored
This change partly addresses a heinous problem we have with the parsing of attribute arguments that are a lone identifier. Previously, we would end up parsing the 'align' attribute of this as an expression "(Align)": template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align((Align)))) char storage[Size]; }; while this would parse as a "parameter name" 'Align': template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align(Align))) char storage[Size]; }; The code that handles the alignment attribute would completely ignore the parameter name, so the while the first of these would do what's expected, the second would silently be equivalent to template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align)) char storage[Size]; }; i.e., use the maximal alignment rather than the specified alignment. Address this by sniffing the "Args" provided in the TableGen description of attributes. If the first argument is "obviously" something that should be treated as an expression (rather than an identifier to be matched later), parse it as an expression. Fixes <rdar://problem/13700933>. llvm-svn: 180973
-
Douglas Gregor authored
llvm-svn: 180972
-
Douglas Gregor authored
This change partly addresses a heinous problem we have with the parsing of attribute arguments that are a lone identifier. Previously, we would end up parsing the 'align' attribute of this as an expression "(Align)": template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align((Align)))) char storage[Size]; }; while this would parse as a "parameter name" 'Align': template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align(Align))) char storage[Size]; }; The code that handles the alignment attribute would completely ignore the parameter name, so the while the first of these would do what's expected, the second would silently be equivalent to template<unsigned Size, unsigned Align> class my_aligned_storage { __attribute__((align)) char storage[Size]; }; i.e., use the maximal alignment rather than the specified alignment. Address this by sniffing the "Args" provided in the TableGen description of attributes. If the first argument is "obviously" something that should be treated as an expression (rather than an identifier to be matched later), parse it as an expression. Fixes <rdar://problem/13700933>. llvm-svn: 180970
-
- Apr 30, 2013
-
-
Richard Smith authored
are now two distinct canonical 'AutoType's: one is the undeduced 'auto' placeholder type, and the other is a deduced-but-dependent type. All deduced-to-a-non-dependent-type cases are still non-canonical. llvm-svn: 180789
-
- Apr 29, 2013
-
-
Richard Smith authored
late-parsed templates. Patch by Faisal Vali! llvm-svn: 180708
-
Richard Smith authored
within a dependent context. Patch by Will Wilson (+clang-format)! llvm-svn: 180702
-
Richard Smith authored
a dependent-scope id expression when a templated member function of a non-templated class references an unknown identifier, since instantiation won't rebuild it (and we can tell at parse time that it'll never work). Based on a patch by Faisal Vali! llvm-svn: 180701
-
- Apr 24, 2013
-
-
Jyotsna Verma authored
llvm-svn: 180208
-
- Apr 08, 2013
-
-
Richard Trieu authored
When two template decls with the same name are used in this diagnostic, force them to print their qualified names. This changes the bad message of: candidate template ignored: could not match 'array' against 'array' to the better message of: candidate template ignored: could not match 'NS2::array' against 'NS1::array' llvm-svn: 179056
-
- Apr 04, 2013
-
-
Jyotsna Verma authored
are unavailable on Hexagon. llvm-svn: 178791
-
- Mar 28, 2013
-
-
Richard Smith authored
Fold together the two implementations of 6.7.3p2 in SemaType. Fix two bugs, each of which was only present in one version: * Give the right diagnostic for 'restrict' applied to a non-pointer, non-reference type. * Don't reject 'restrict' applied indirectly to an Objective-C object pointer type (eg, through template instantiation). llvm-svn: 178200
-
Richard Smith authored
Don't reject __restrict applied to a dependent type; it might instantiate to a pointer or reference type. llvm-svn: 178198
-
- Mar 27, 2013
-
-
rdar://problem/13267210Douglas Gregor authored
<rdar://problem/13267210> Ensure that Sema::CompareReferenceRelationship returns consistent results with invalid types. When Sema::RequireCompleteType() is given a class template specialization type that then fails to instantiate, it returns 'true'. On subsequent invocations, it can return false. Make sure that this difference doesn't change the result of Sema::CompareReferenceRelationship, which is expected to remain stable while we're checking an initialization sequence. llvm-svn: 178088
-
- Mar 14, 2013
-
-
John McCall authored
template instantiation will still consider them to be definitions if we instantiate the containing class before we get around to parsing the friend. This seems like a legitimate use of "late template parsed" to me, but I'd appreciate it if someone responsible for the MS feature would look over this. This file already appears to access AST nodes directly, which is arguably not kosher in the parser, but the performance of this path matters enough that perpetuating the sin is justifiable. Probably we ought to reconsider this policy for very simple manipulations like this. The reason this entire thing is necessary is that function template instantiation plays some very gross games in order to not associate an instantiated function template with the class it came from unless it's a definition, and the reason *that's* necessary is that the AST currently cannot represent the instantiation history of individual function template declarations, but instead tracks it in common for the entire function template. That probably prevents us from correctly reporting ill-formed calls to ambiguously instantiated friend function templates. rdar://12350696 llvm-svn: 177003
-
- Mar 08, 2013
-
-
rdar://problem/13094134Douglas Gregor authored
<rdar://problem/13094134> Don't try to wire up typedef names for invalid anonymous tag declarations encountered during template instantiation. llvm-svn: 176727
-
rdar://problem/13140795Douglas Gregor authored
<rdar://problem/13140795> Transform the scope type of a pseudo-destructor expression within the object scope. We were transforming the scope type of a pseudo-destructor expression (e.g., the first T in x->T::~T()) as a freestanding type, which meant that dependent template specialization types here would stay dependent even when no template parameters were named. This would eventually mean that a dependent expression would end up in what should be fully-instantiated ASTs, causing IRgen to assert. llvm-svn: 176723
-
- Mar 05, 2013
-
-
David Blaikie authored
llvm-svn: 176474
-
- Feb 27, 2013
-
-
David Blaikie authored
llvm-svn: 176216
-
David Blaikie authored
Functionality committed in r172585 but tested the function case without the array case. llvm-svn: 176215
-
- Feb 22, 2013
-
-
Richard Smith authored
llvm-svn: 175875
-
- Feb 02, 2013
-
-
Richard Smith authored
designator" diagnostic with more correct and more human-friendly "cannot take address of rvalue of type 'T'". For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully saying "cannot take address of rvalue of type '<overloaded function type>'". For the case of &array_temporary, treat it just like a class temporary (including allowing it as an extension); the existing diagnostic wording for the class temporary case works fine. llvm-svn: 174262
-
- Jan 31, 2013
-
-
Richard Smith authored
have a direct mismatch between some component of the template and some component of the argument. The diagnostic now says what the mismatch was, but doesn't yet say which part of the template doesn't match. llvm-svn: 174039
-
- Jan 16, 2013
-
-
Douglas Gregor authored
parameters (per C++ [temp.param]p8) when computing the type of a reference to a non-type template parameter. Fixes <rdar://problem/13000548>. llvm-svn: 172585
-
- Dec 22, 2012
-
-
Richard Smith authored
PR14695: Fix assert from bad cast<>. Not every namespace is a NamespaceDecl; it might instead be a TranslationUnitDecl. llvm-svn: 170976
-