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

Reply via email to