This is the mail archive of the
mailing list for the GCC project.
Re: [C++1y] [PATCH 3/4] ... canonical type workaround and refactoring
- From: Jason Merrill <jason at redhat dot com>
- To: Adam Butcher <adam at jessamine dot co dot uk>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 25 Sep 2013 11:01:26 -0500
- Subject: Re: [C++1y] [PATCH 3/4] ... canonical type workaround and refactoring
- Authentication-results: sourceware.org; auth=none
- References: <1379615867-21555-1-git-send-email-adam at jessamine dot co dot uk> <1379615867-21555-4-git-send-email-adam at jessamine dot co dot uk> <523C8A39 dot 1080405 at redhat dot com> <34c9b6cbb7860e48a4514527655a22ef at imap dot force9 dot net> <362b88f42a39538fcb50b79ab526ac6a at imap dot force9 dot net> <3c94265be0a93211393264ac16908baa at imap dot force9 dot net> <165bade905bac2f8ffafc15f73bc23a6 at imap dot force9 dot net>
On 09/24/2013 02:05 AM, Adam Butcher wrote:
Shall I push the patch below to trunk as an intermediate workaround
whilst I get to refactoring to support on-the-fly template parm synthesis?
I think let's wait for a better fix.
On the subject of on-the-fly synthesis: I haven't started yet but I'm
thinking to trigger in 'cp_parser_simple_type_specifier' when
'current_binding_level->kind == sk_function_parms'. I can foresee a
potential issue with packs in that, upon reading the 'auto' (potentially
nested in some other type), a plain template parm will be synthesized;
but it may need to be a pack parm type if '...' is found later.
Hmm, good point.
I think there are two options:
1) Build up the type as normal and use tsubst to replace the non-pack
template parameter with a pack if needed.
2) If we see 'auto', scan ahead (possibly via tentative parsing) to see
if there's a ...