On 09/11/2013 02:22 PM, Adam Butcher wrote:
Okay for the attached to go to trunk with suitable changelog?
Yes.
Jason
On 11.09.2013 16:25, Jason Merrill wrote:
On 09/11/2013 10:42 AM, Jason Merrill wrote:
Sounds like the problem is that the compiler is trying to
instantiate a
function while cp_unevaluated_operand is set. But that shouldn't be
an
issue because push_to_top_level clears cp_unevaluated_operand.
On 09/11/2013 10:42 AM, Jason Merrill wrote:
Sounds like the problem is that the compiler is trying to instantiate a
function while cp_unevaluated_operand is set. But that shouldn't be an
issue because push_to_top_level clears cp_unevaluated_operand. How does
it come to be set when instantiatin
On 09/11/2013 03:38 AM, Adam Butcher wrote:
This is not a complete enough description. It only ICEs instantiating
the call op through the decltype return of the conversion op if the
return type of the call op is a deduced one (i.e. unspecified or
specified explicitly as 'auto'). If the lambda c
On 10.09.2013 03:19, Adam Butcher wrote:
- Instantiation of generic conversion op ICEs if the call op
contains
declarations and hasn't already been instantiated.
This is not a complete enough description. It only ICEs instantiating
the call op through the decltype return of the conversion
Hi Jason,
Here's the latest patch set; reduced to two patches now.
Remaining issues:
- Instantiation of generic conversion op ICEs if the call op contains
declarations and hasn't already been instantiated.
- Still haven't figured out a clean way to make 'auto...' work.
Cheers,
Adam
Patch s
On 09/02/2013 02:27 PM, Adam Butcher wrote:
Bug 41933 is specifically about lambda capture; I think you're
running into something else.
The problem is in expanding the 'ts' capture from the 5.1.2.5. It
looks like this:
1 auto vglambda = [](auto printer) {
2 return [=](auto&& ... ts) {
On 01.09.2013 21:05, Jason Merrill wrote:
On 08/27/2013 03:42 PM, Adam Butcher wrote:
I don't know if it's the correct thing to do but the implementation
currently omits the conversion to function pointer operator if the
argument list contains a parameter pack.
I would expect that to work. Do
On 08/27/2013 03:42 PM, Adam Butcher wrote:
Unfortunately, due to errors being thrown 'early' in grokdeclarator, I
haven't been able to get 'auto...' (or reference/qualified variants)
working yet. I think I need to defer processing the parameter pack
internals of grokdeclarator until I have the
Hi Jason,
Here's an updated patch set. The fully_implicit_function_template_p
field has been moved into cp_parser and the other comments addressed.
I've done some testing with parameter packs also. They work okay with
the explicit template parameter syntax for lambdas.
Unfortunately, due to er
Hi Jason,
I decided to go ahead and submit the latest cleaned up version of the generic
lambda and implicit function template patches. I think all review comments have
been addressed. As well as the cleanup there are a few enhancements; generic
lambda instantiations in diagnostics now show templ
11 matches
Mail list logo
