<div dir="ltr">Thanks. Comments noted. I'm working on clean up + tests cases.<div style>I am however finding that some important test cases require support for explicit specializations </div><div style>(not necessarily partial specialization yet). </div>

<div style>So I'm trying to complete that part as well before the next (partial) patch.</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 7:00 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Larisse,<br>
<br>
This looks like a great start!<br>
<br>
Adding two pointers to every VarDecl to support this seems like quite<br>
a high cost to pay. The DefinitionData field looks unnecessary (we can<br>
reconstruct the definition by following the redeclaration chain<br>
already), and if you drop that you should be able to remove the extra<br>
parameter to VarDecl::Create too. Can you find somewhere else to hang<br>
the TemplateOrInstantiation data, so we don't need to pay for it if we<br>
don't use it? (Maybe derive from the ExtInfo in DeclaratorDecl and put<br>
the data there, or add a class derived from VarDecl for the cases<br>
where we need this data, or put it in a DenseMap on the ASTContext.)<br>
<br>
+      return IsVarTemplate? NameClassification::TypeTemplate(Template)<br>
+              : NameClassification::VarTemplate(Template);<br>
<br>
This looks backwards.<br>
<br>
+      if (!getLangOpts().CPlusPlus1y) {<br>
+        if (TemplateParams->size() > 0) {<br>
+          // There is no such thing as a variable template.<br>
+          Diag(D.getIdentifierLoc(), diag::err_template_variable)<br>
+            << II<br>
+            << SourceRange(TemplateParams->getTemplateLoc(),<br>
+                           TemplateParams->getRAngleLoc());<br>
<br>
Can you downgrade this from an Error to an ExtWarn? There doesn't seem<br>
to be a good reason not to support variable templates as an extension<br>
in all C++ language modes.<br>
<br>
This patch needs some cleaning up to prepare for check in (removing<br>
commented-out code etc), and a lot more tests; I suggest going over<br>
the patch and trying to add some tests for every change, where that's<br>
possible. Other than that, this seems close to being ready to commit,<br>
as a first step towards variable templates.<br>
<br>
Thank you!<br>
<div><div class="h5"><br>
On Tue, Jun 18, 2013 at 5:50 PM, Larisse Voufo <<a href="mailto:lvoufo@google.com">lvoufo@google.com</a>> wrote:<br>
> There was a bug in this earlier version of the patch. The correction is<br>
> attached.<br>
><br>
><br>
> On Wed, Jun 12, 2013 at 6:52 PM, Larisse Voufo <<a href="mailto:lvoufo@google.com">lvoufo@google.com</a>> wrote:<br>
>><br>
>> Hello --<br>
>><br>
>> I have  started implementing variable templates, and you can find attached<br>
>> the current state.<br>
>> While it may cover more cases, the only guarantee it has is that top level<br>
>> variable templates can be declared and used (as illustrated in the<br>
>> SemaCXX/cxx1y-variable-templates.cpp test file). That is, it does not yet<br>
>> cover any of the following:<br>
>><br>
>> * variable template explicit (partial) specialization and instantiations,<br>
>> * static member variable templates,<br>
>> * constexpr variables, and<br>
>> * default variable template arguments.<br>
>><br>
>> Things will get much cleaner as I complete the implementation.<br>
>><br>
>> Thanks,<br>
>> -- Larisse.<br>
>><br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
><br>
</blockquote></div><br></div>