diff options
author | Patrick Palka <ppalka@redhat.com> | 2024-05-14 22:55:16 -0400 |
---|---|---|
committer | Patrick Palka <ppalka@redhat.com> | 2024-05-14 22:55:16 -0400 |
commit | c6cc6d4741a880109c4e0e64d5a189687fb526f6 (patch) | |
tree | 9498d88c819c00302bf8371a7d341f722090ff81 /gcc/cp/parser.cc | |
parent | 32ff344d57d56fddb66c4976b5651345d40b7157 (diff) | |
download | gcc-c6cc6d4741a880109c4e0e64d5a189687fb526f6.zip gcc-c6cc6d4741a880109c4e0e64d5a189687fb526f6.tar.gz gcc-c6cc6d4741a880109c4e0e64d5a189687fb526f6.tar.bz2 |
c++: lvalueness of non-dependent assignment expr [PR114994]
r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment
expressions ahead of time and give them a type, as was already done for
compound assignments. Unlike for compound assignments however, if a
simple assignment resolves to an operator overload we represent it as a
(typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload.
(I reckoned this was at worst a pessimization -- we'll just have to repeat
overload resolution at instantiatiation time.)
But this turns out to break the below testcase ultimately because
MODOP_EXPR (of non-reference type) is always treated as an lvalue
according to lvalue_kind, which is incorrect for the MODOP_EXPR
representing x=42.
We can fix this by representing such class assignment expressions as
CALL_EXPRs as well, but this turns out to require some tweaking of our
-Wparentheses warning logic and may introduce other fallout making it
unsuitable for backporting.
So this patch instead fixes lvalue_kind to consider the type of a
MODOP_EXPR representing a class assignment.
PR c++/114994
gcc/cp/ChangeLog:
* tree.cc (lvalue_kind) <case MODOP_EXPR>: For a class
assignment, consider the result type.
gcc/testsuite/ChangeLog:
* g++.dg/template/non-dependent32.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Diffstat (limited to 'gcc/cp/parser.cc')
0 files changed, 0 insertions, 0 deletions