On Thu, Feb 8, 2018 at 1:21 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > On 08/02/2018 18:38, Jason Merrill wrote: >> >> On Thu, Feb 8, 2018 at 6:22 AM, Paolo Carlini <paolo.carl...@oracle.com> >> wrote: >>> >>> Hi, >>> >>> this one should be rather straightforward. As noticed by Jakub, we >>> started >>> emitting the spurious warning with the fix for c++/69257, which, among >>> other >>> things, fixed decay_conversion wrt mark_rvalue_use and mark_lvalue_use >>> calls. In particular it removed the mark_rvalue_use call at the very >>> beginning of the function, thus now a PARM_DECL with NULLPTR_TYPE as >>> type, >>> being handled specially at the beginning of the function, doesn't get the >>> mark_rvalue_use treatment - which, for example, POINTER_TYPE now gets >>> later. >>> I'm finishing testing on x86_64-linux the below. Ok if it passes? >> >> A future -Wunused-but-set-variable might warn about the dead store to >> exp; let's just discard the result of mark_rvalue_use. OK with that >> change. > > Agreed, thanks. By the way, maybe it's the right occasion to voice that I > find myself often confused about this topic, that is which specific > functions are modifying their arguments and there isn't a specific reason to > assign the return value. I ask myself: why then we return something instead > of void? Maybe just convenience while writing some expressions? Would make > sense. Then, would it make sense to find a way to "mark" the functions which > are modifying their arguments? Sometimes isn't immediately obvious because > we are of course passing around pointers and using typedefs to obfuscate the > whole thing. Maybe we should just put real C++ to good use ;)
Well, usually we want to assign the result of mark_rvalue_use, it's just that in this case we're returning nullptr_node instead of exp. Jason