[PATCH] Addresses TemplateParameterDepth calculation of Local Member templates

[Richard Smith]

Thanks, fixed up slightly and committed as r180708.

Do we need a similar change for the calls to ActOnReenterTemplateScope in
Parser::ParseLexedAttribute(s) ?


On Sun, Apr 28, 2013 at 9:31 PM, Faisal Vali <faisalv at gmail.com> wrote:

> Here is a patch for calculating the TemplateParameterDepth correctly,
> built upon Will Wilson's patch (and includes his code -  i hope that's ok
> to do?).
> Please let me know what you think - or if you need me to submit it a
> different way ....
> Thanks!
>
> Faisal Vali
>
>
>
> On Sat, Apr 27, 2013 at 7:46 PM, Faisal Vali <faisalv at gmail.com> wrote:
>
>>
>>
>> On Sat, Apr 27, 2013 at 5:52 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>>
>>> +  assert( Actions.getDiagnostics().hasErrorOccurred() ||
>>> +        (!dyn_cast<FunctionTemplateDecl>(LM.D) ||
>>> +
>>>  (dyn_cast<FunctionTemplateDecl>(LM.D)->getTemplateParameters()->
>>> +              getDepth() < TemplateParameterDepth)) &&
>>> "TemplateParameterDepth"
>>> +              " should be greater than the depth of current template
>>> being"
>>> +              " instantiated!");
>>>
>>> No space after (, extra space on the next line, and this will generate a
>>> || versus && precedence warning. Also, would be more consistent to reflow
>>> the string literal to start on its own line.
>>>
>>> +    // getNumTemplateParameterLists returns the number of TPLs
>>> +    // minus the TPL of the actual function being instantiated
>>> +    // i.e. consider a nested member class template with
>>> +    // a template member of a function defined out of class ... its
>>> +    // associated TPLs
>>> +    // Therefore we add 1 to the depth for the Declarator itself
>>> +    // and the rest for the outer TPLs returned by getNumTPLs
>>>
>>> Something seems to be missing from the first part of this comment. In
>>> any case, IIRC there's a patch in flight which removes this code and makes
>>> it call ActOnReenterTemplateScope the right number of times.
>>>
>>>
>> ok - I shall wait for you to commit that patch, then update my code
>> against trunk - and then incorporate all your comments and resubmit this
>> patch.
>>
>> Any thoughts on the dependent bases patch for ms-compatibility?
>>
>> Also can I start emailing you some interim patches for generic-lambdas,
>> even though they are not entirely functional - but I could use feedback on
>> the approach and the API's used early on before I go down the wrong rabbit
>> hole?
>>
>> thanks!
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130429/34af38e2/attachment.html>