This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- From: Adam Butcher <adam at jessamine dot co dot uk>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Gcc Patches <gcc-patches at gcc dot gnu dot org>, <daniel dot kruegler at googlemail dot com>, Volker Reichelt <reichelt at gcc dot gnu dot org>
- Date: Wed, 16 Oct 2013 03:13:04 +0100
- Subject: Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- Authentication-results: sourceware.org; auth=none
- References: <08a6b60986417d8ab134b6aa85ecd80e at imap dot force9 dot net> <5254CF91 dot 500 at redhat dot com> <0c2ee45ea87bab94392e93f3a7b20d90 at imap dot force9 dot net> <28fc47918050276d671ca11a2d74cf3a at imap dot force9 dot net>
On 2013-10-15 22:21, Adam Butcher wrote:
On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote:
>
> 2) If we see 'auto', scan ahead (possibly via tentative parsing) to
see if there's a ...
>
My current preferred option. The problem with it is that, ideally, I
only want to look ahead for '...' in the parm decl if an 'auto' is
seen. But I'm not sure how to do this in the case where the first
'auto' is nested in a template parameter (or other complex type).
E.g.
auto f(pair<pair<auto, auto>, auto>... v)
^
From the 'auto' I'd need to unwind to the fn parm scope and then try
to tentatively parse the ellipsis. To unwind and look ahead for
'...'
needs the full parser mechanics but without any side-effects. I
don't
think I can do it with the lexer alone as I think there may be
ambiguity with scanning <, <<, >, >> tokens.
Look-ahead seems like the right way to go (unless there's a way to
defer type hashing) but I'm not sure how to achieve it.
I've got a [potential] [partial] solution to this. It doesn't handle
edge cases but I believe it will handle the majority of cases.
By maintaining a nesting counter of calls to
cp_parser_enclosed_template_argument_list we can determine, for a
particular parm, what level of template-id were are parsing when we see
an 'auto'. A tentative skip parse handling < << ( [ ] ) >> > can be
done until reaching an ellipsis or, if <> nesting count drops to zero,
a closing paren or comma terminating the parm. Mismatches would also
be considered as terminating the parm.
In the ellipsis case we assume some sort of pack. If the <> nesting
count is zero when an ellipsis is found, we assume a function parameter
pack and flag that all 'auto's in the parm should be type packs and
don't need to do the look-ahead again for this parm. If the <> nesting
count is non-zero when an ellipsis is found, then only the 'auto's
within that level of template argument list are considered type packs
and look-ahead will be done for 'auto' found in subsequent template
argument lists within the parm.
The latter case implements the implicit type pack extension supporting,
for example, the following:
f(tuple<auto,tuple<auto...>,tuple<auto...>> t)
This doesn't handle cases where < << >> > are used as operators within
the parm but I think that's an edge case and it would only affect
whether the 'auto' was considered an implicit type pack or not.
I haven't gone all the way with this theory yet, but it could be a
plausible solution.
Let me know what you think.
Cheers,
Adam
- References:
- [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.