On Apr 4, 2018, Jason Merrill wrote:
>> else
>> expr = lookup_template_function (expr, template_args);
>> +
>> + /* We may be repeating a check already done during parsing, but
>> +if it was well-formed and passed then, it will pass again
>> +now, and if it didn't, we wouldn
On Tue, Apr 3, 2018 at 10:38 PM, Alexandre Oliva wrote:
> On Apr 3, 2018, Jason Merrill wrote:
>
>> On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva wrote:
>>> On Apr 2, 2018, Jason Merrill wrote:
>>>
On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
> On Mar 30, 2018, Jason Me
On Apr 3, 2018, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva wrote:
>> On Apr 2, 2018, Jason Merrill wrote:
>>
>>> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
On Mar 30, 2018, Jason Merrill wrote:
template
void foo(T t) {
typename
On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva wrote:
> On Apr 2, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
>>> On Mar 30, 2018, Jason Merrill wrote:
>>> template
>>> void foo(T t) {
>>> typename T::template C u = t;
>>> T::template C (t);
>>
On Apr 2, 2018, Jason Merrill wrote:
> On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
>> On Mar 30, 2018, Jason Merrill wrote:
>> template
>> void foo(T t) {
>> typename T::template C u = t;
>> T::template C (t);
>> T::template C::f (t, u);
>> }
> We should be able to distingu
On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
> On Mar 30, 2018, Jason Merrill wrote:
>
>> True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
>> IDENTIFIER_NODE. Looking at tsubst_copy_and_build, I see that we
>> don't call finish_id_expression when substituting such a
>
On Mar 30, 2018, Jason Merrill wrote:
> True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
> IDENTIFIER_NODE. Looking at tsubst_copy_and_build, I see that we
> don't call finish_id_expression when substituting such a
> TEMPLATE_ID_EXPR. So maybe lookup_template_function and
> loo
On Mar 30, 2018, Jason Merrill wrote:
> On Thu, Mar 29, 2018 at 6:24 PM, Alexandre Oliva wrote:
>> AFAICT we wouldn't always know, within cp_parser_template_id, whether
>> the id is a type or a function.
> True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
> IDENTIFIER_NODE. Lo
On Thu, Mar 29, 2018 at 6:24 PM, Alexandre Oliva wrote:
> On Mar 28, 2018, Jason Merrill wrote:
>
>> On Wed, Mar 28, 2018 at 5:06 AM, Alexandre Oliva wrote:
>>> On Mar 23, 2018, Jason Merrill wrote:
>>>
On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
> + /* Concepts allows 'a
On Mar 28, 2018, Jason Merrill wrote:
> On Wed, Mar 28, 2018 at 5:06 AM, Alexandre Oliva wrote:
>> On Mar 23, 2018, Jason Merrill wrote:
>>
>>> On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
+ /* Concepts allows 'auto' in template arguments, even multiple
+ 'auto's in
On Wed, Mar 28, 2018 at 5:06 AM, Alexandre Oliva wrote:
> On Mar 23, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
>>> + /* Concepts allows 'auto' in template arguments, even multiple
>>> + 'auto's in a single argument.
>
>> I think that's only inte
On Mar 23, 2018, Jason Merrill wrote:
> On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
>> + /* Concepts allows 'auto' in template arguments, even multiple
>> + 'auto's in a single argument.
> I think that's only intended for class templates;
Aah, that explains a lot! Dang, it wa
On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva wrote:
> + /* Concepts allows 'auto' in template arguments, even multiple
> + 'auto's in a single argument.
I think that's only intended for class templates; we should reject
'auto' as a template argument for function or variable templates.
J
We fail to detect unresolved explicitly-passed auto template args.
The first hunk in pt.c, that changes fn_type_unification, arranges for
us to regard the template arg list as incomplete, although that's not
necessary for any of the testcases I tried. I thought it might be
relevant in case the ar
14 matches
Mail list logo
