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
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
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,
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
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 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
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
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
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
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:
+ /*
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
>>> +
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;
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
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
14 matches
Mail list logo