From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 110E1385F015 for ; Thu, 25 Aug 2022 21:49:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 110E1385F015 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661464146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5xNVzbGDV2ds5pmEZT9L+LNt0pSzGzkWeRvmHmY4Fr0=; b=fghvXYGva27fyPaeDBsWFR+36k3uiLzzUaEOY/by/6FWtFvXi09R3xb6YVXoLEumStHBS1 NOuaXhjjPO7g+IVONLW5mOyxfinzfRePYqSBQgZLvOwUJaIrr1Pexsm7NP6N17uVYhxE7F 1X+edjhs0oOJFsmUEczy6evPjFwPl3c= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-632-Hec31H-nPIywc9blqXWPLQ-1; Thu, 25 Aug 2022 17:49:06 -0400 X-MC-Unique: Hec31H-nPIywc9blqXWPLQ-1 Received: by mail-qv1-f69.google.com with SMTP id dh19-20020ad458d3000000b00496bf7e4a72so11860543qvb.0 for ; Thu, 25 Aug 2022 14:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=5xNVzbGDV2ds5pmEZT9L+LNt0pSzGzkWeRvmHmY4Fr0=; b=awyacwQmjFmQLC2Tp9mZlzHm65Y15xzZCjl0BziEiM7+vDisEGJ9+F094669r57k4o 76VWLps2u58HYBHgA71Bzh00Vykq5c5MPatzCsEeIoUP98N0FJxl7mqweBBUxD4kNOQU 3/qCLu+OB6m8S4Ldvnng2Pfn5qNzqUTueOEhmWSX0stHI51CKCk1fSM0l75g23jSqxdc qESNgaOSdH9nctqIAXD7WbZuTFrCp+CeRtHz0s8WlJ+Lm+lpAP8eXsEbtxlpjDEQVOYN ifnQmEP3stGtpcZY6KYhI0tAFnsu+pf2MLjD0LcHD2qU7WjXXXtcme2+vXn3yD5y3ss7 VHJw== X-Gm-Message-State: ACgBeo3KViQy9kAPzW4Jun2QRwpBdkDiAIdZ7SFoCvxHNBure2gLjzo/ 7FQYwFAchM/HUF8G1as3Zde74ccX4F5Vwy5e8dEiECdqZwE9zJd0fTqVbi5G0HwBY/Ivw2WZGdu PaJ/HiJX5/SsxLxVICw== X-Received: by 2002:a37:2c06:0:b0:6bb:242:d117 with SMTP id s6-20020a372c06000000b006bb0242d117mr4636968qkh.234.1661464144963; Thu, 25 Aug 2022 14:49:04 -0700 (PDT) X-Google-Smtp-Source: AA6agR7QfCAvgrxYZVSC/ZU4puuoO+cfUF0yvGRer7PACrEauKoTJIki1fL0BGHkCh0+1T7iAQEzcg== X-Received: by 2002:a37:2c06:0:b0:6bb:242:d117 with SMTP id s6-20020a372c06000000b006bb0242d117mr4636960qkh.234.1661464144723; Thu, 25 Aug 2022 14:49:04 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::e531]) by smtp.gmail.com with ESMTPSA id f62-20020a37d241000000b006b9ab3364ffsm435395qkj.11.2022.08.25.14.49.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 14:49:04 -0700 (PDT) Date: Thu, 25 Aug 2022 17:49:02 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH v4] c++: Implement -Wself-move warning [PR81159] Message-ID: References: <20220809163719.381319-1-polacek@redhat.com> <1ca5b35f-0fa6-be28-290f-701c5ac43807@redhat.com> <3e9dea44-1e0e-e329-575a-aa621d19deeb@redhat.com> <9e980813-7ab7-25dc-7f74-56faaafafb84@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.6 (2022-06-05) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Aug 25, 2022 at 09:25:43AM -0400, Jason Merrill wrote: > On 8/24/22 17:30, Marek Polacek wrote: > > On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: > > > On 8/23/22 09:39, Marek Polacek wrote: > > > > + tree arg = CALL_EXPR_ARG (fn, 0); > > > > + extract_op (arg); > > > > + if (TREE_CODE (arg) == ADDR_EXPR) > > > > + arg = TREE_OPERAND (arg, 0); > > > > + tree type = TREE_TYPE (lhs); > > > > + lhs = maybe_undo_parenthesized_ref (lhs); > > > > + STRIP_ANY_LOCATION_WRAPPER (lhs); > > > > + const bool print_var_p = (DECL_P (lhs) > > > > + || REFERENCE_REF_P (lhs) > > > > + || TREE_CODE (lhs) == COMPONENT_REF); > > > > > > Why include REFERENCE_REF_P and COMPONENT_REF? Reference refs should be > > > stripped before this test, member refs aren't variables. > > > > I'm checking REFERENCE_REF_P and COMPONENT_REF to say "moving a variable" > > in #1 and #3. The REFERENCE_REF_P check means that we also say "variable" > > for #2. Sure, "A variable is introduced by the declaration of a reference > > other than a non-static data member", but I'm not sure if users care about > > that here? > > > > If I strip REFERENCE_REFs before the check then the result will be the > > same. > > That's what I was suggesting, yes: Strip the REFERENCE_REF so DECL_P can see > the decl. Ok, I've added the REFERENCE_REF stripping. But I've still left the COMPONENT_REF in. Perhaps we could say "moving a member" to itself for COMPONENT_REFs. Or just say "moving 'x' of type 'int' to itself" and avoid all of this. :) > I don't see where COMPONENT_REF comes in? For #1 in the test below the COMPONENT_REF was created in finish_id_expression -> finish_non_static_data_member -> build_class_member_access_expr and passed down to maybe_warn_self_move from here: #0 maybe_warn_self_move (loc=2147483652, lhs=, rhs=) at /home/mpolacek/src/gcc/gcc/cp/typeck.cc:8908 #1 0x0000000000f3d03e in cp_build_modify_expr (loc=2147483652, lhs=, modifycode=NOP_EXPR, rhs=, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck.cc:9161 #2 0x0000000000f3e461 in build_x_modify_expr (loc=2147483652, lhs=, modifycode=NOP_EXPR, rhs=, lookups=, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck.cc:9446 #3 0x0000000000d92d4e in cp_parser_assignment_expression (parser=0x7fffea236850, pidk=0x0, cast_p=false, decltype_p=false) at /home/mpolacek/src/gcc/gcc/cp/parser.cc:10461 > > Or I could keep only the DECL_P check, but then we'll say "moving > > an expression" for #1 and #2, which seems strange. > > > > struct S { > > int x; > > int &r; > > void foo () { > > x = std::move (x); // #1 > > r = std::move (r); // #2 > > }; > > }; > > > > void > > foo (int &r) > > { > > r = std::move (r); // #3 > > } Marek