[PATCH] Instantiate static constexpr member function of a local struct in a function template earlier.

[Michael Park]

I've got a follow-up patch which I think addresses an existing bug that
hadn't surfaced.

In the *ParseLateTemplatedFuncDef* function in *lib/Parse/ParseTemplate.cpp*,
we build up the sequence of DeclContext


On 29 April 2015 at 11:20, Michael Park <mcypark at gmail.com> wrote:

> Ah, that's unfortunate. I'll take a look. Thanks!
>
> On 28 April 2015 at 20:33, Richard Smith <richard at metafoo.co.uk> wrote:
>
>> One of our buildbots seems unhappy:
>>
>>
>> http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/11939/steps/test_all/logs/Clang-Unit%20%3A%3A%20ASTMatchers__ASTMatchersTests__HasAncestor.MatchesClosestAncestor
>>
>> Its testcase is this:
>>
>>       template <typename T> struct C {
>>         void f(int) {
>>           struct I { void g(T) { int x; } } i; i.g(42);
>>         }
>>       };
>>       template struct C<int>;
>>
>> It looks like the problem is some interaction of your patch and delayed
>> template parsing (running the above code through clang with
>> -fdelayed-template-parsing reproduces the issue). Can you take a look?
>>
>> On Tue, Apr 28, 2015 at 5:23 PM, Michael Park <mcypark at gmail.com> wrote:
>>
>>> Awesome, Thanks Richard!
>>>
>>> On 28 April 2015 at 20:11, Richard Smith <richard at metafoo.co.uk> wrote:
>>>
>>>> On Tue, Apr 28, 2015 at 4:00 PM, Michael Park <mcypark at gmail.com>
>>>> wrote:
>>>>
>>>>> The answer is that we don't really know. It would be more consistent
>>>>>> with the non-template case for it to be ill-formed (it also seems
>>>>>> reasonable to say that you can't instantiate a member function until its
>>>>>> class is complete), but the point of instantiation rules for constexpr
>>>>>> functions aren't settled yet; this is part of DR1581 (still open).
>>>>>>
>>>>>
>>>>> Agreed. Thanks for the pointer to DR1581!
>>>>>
>>>>> LGTM
>>>>>
>>>>>
>>>>> As this is my first patch for Clang, I'm not all that familiar with
>>>>> the required process to get this patch committed. Am I required to do
>>>>> anything further on my end?
>>>>>
>>>>
>>>> I've committed your patch as r236063. Feel free to go ahead and
>>>> mark PR20625 as fixed. Thanks!
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> MPark.
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150501/6d26fe78/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr20625.patch
Type: application/octet-stream
Size: 2567 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150501/6d26fe78/attachment.obj>