On Mar 2, 2018, Jason Merrill wrote:
> Let's add a comment along the lines of
> /* Let lvalue_kind know this was a glvalue. */
> OK with that change.
Thanks, here's what I'm about to check in.
[C++] [PR84231] overload on cond_expr in template
A non-type-depe
get here for a type-dependent expression? I'd think
>> we'd never get as far as asking whether a type-dependent expression is
>> an lvalue, since in general we can't answer that question.
>
> We shouldn't, indeed. And AFAICT we don't; I've added an as
for a COND_EXPR of class type.
or array, like the default case, I suppose.
> Can we actually get here for a type-dependent expression? I'd think
> we'd never get as far as asking whether a type-dependent expression is
> an lvalue, since in general we can't answer that
On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva wrote:
> + if (processing_template_decl)
> +result_type = cp_build_reference_type (result_type, !is_lvalue);
If !is_lvalue, we don't want a reference type at all, as the result is
a prvalue. is_lvalue should probably rename to is_glvalue.
T
nly
unexpected glitch was the need for adjusting the fold expr parser to
deal with an indirect_ref, lest g++.dg/cpp1x/fold6.C would fail to
error at the line with the ternary operator.
Ok to install?
[C++] [PR84231] overload on cond_expr in template
A non-type-dependent COND_EXPR within
On Tue, Feb 27, 2018 at 1:05 PM, Alexandre Oliva wrote:
> On Feb 15, 2018, Jason Merrill wrote:
>
>> On Thu, Feb 8, 2018 at 9:09 PM, Alexandre Oliva wrote:
>>> + /* If it was supposed to be an rvalue but it's not, adjust
>>> +one of the operands so that any overload resolutio
On Feb 15, 2018, Jason Merrill wrote:
> On Thu, Feb 8, 2018 at 9:09 PM, Alexandre Oliva wrote:
>> + /* If it was supposed to be an rvalue but it's not, adjust
>> +one of the operands so that any overload resolution
>> +taking this COND_EXPR as an operand makes the
On Thu, Feb 8, 2018 at 9:09 PM, Alexandre Oliva wrote:
> + /* If it was supposed to be an rvalue but it's not, adjust
> +one of the operands so that any overload resolution
> +taking this COND_EXPR as an operand makes the correct
> +decisions. See c++/8
A non-type-dependent COND_EXPR within a template is reconstructed with
the original operands, after one with non-dependent proxies is built to
determine its result type. This is problematic because the operands of
a COND_EXPR determined to be an rvalue may have been converted to denote
their rvalu
