On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const version is a better match than the
const, so we should pick that one in overload resolution, but if we
remove the const version, the other one seems valid to me
Hmm, you're right, I was confused.
Jason
On 06/20/2014 03:11 PM, Jason Merrill wrote:
On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const version is a better match than the
const, so we should pick that one in overload resolution, but if we
remove the const version, the other one seems valid to me
Hmm,
On 06/19/2014 12:12 AM, Jason Merrill wrote:
We were treating a const member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
In 4.9 we also need to set LOOKUP_NO_TEMP_BIND.
commit 48ca9803695872d984b0f4efa56f7f58987d0928
On Thu, 19 Jun 2014, Jason Merrill wrote:
We were treating a const member function like a normal const reference, and
binding an rvalue object argument to it. But it doesn't work that way.
That looks weird to me. The const version is a better match than the
const, so we should pick that
We were treating a const member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 20a165532a9b0b0dada391716a1fb781af3ec005
Author: Jason Merrill ja...@redhat.com
Date: Wed
