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.129.124]) by sourceware.org (Postfix) with ESMTPS id A5AD93858D37 for ; Fri, 28 Apr 2023 09:55:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5AD93858D37 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=1682675705; 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=pWJ698hJIv1bdTu/0x/siLLK5+krF5MD6iQIyXJGFXY=; b=jV9+oO9RPat77hRtRbDy7IyqqYClTlPyJlQgNThOICe9UWPKkvEENAacA+aDnSngpkkDgk +sfXpUwlIdyqKfUE+P0zM0RPHoQ7w/yN52U5uKawwYXqTtDgu0eOmanEhb3z0PY5dYBiXp PFhZUJZOQkvY5mx4AXDjHhsesCd8E34= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-217-KS6vhZ05PnSWaNeC7CPQxg-1; Fri, 28 Apr 2023 05:55:03 -0400 X-MC-Unique: KS6vhZ05PnSWaNeC7CPQxg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DC2CE811E7E for ; Fri, 28 Apr 2023 09:55:02 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0FB7640C6EC4; Fri, 28 Apr 2023 09:55:01 +0000 (UTC) From: Florian Weimer To: Stephan Bergmann via Gcc Cc: Stephan Bergmann Subject: Re: GCC/Clang attributes guiding warnings about unused entities References: Date: Fri, 28 Apr 2023 11:55:00 +0200 In-Reply-To: (Stephan Bergmann via Gcc's message of "Thu, 27 Apr 2023 00:03:36 +0200") Message-ID: <87h6t08h6z.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Stephan Bergmann via Gcc: > [cross-posting this to both the GCC and Clang communities] I don't see your post here: I don't think this is expected to work from a Discourse point of view. > * __attribute__((unused)) behaves mostly the same as [[maybe_unused]]. > > The one difference is that __attribute__((unused)) applied to a type > does not warn about that type being unused, but rather warns about > unreferenced variables of that type. And it appears that both GCC and > Clang implement [[maybe_unused]] with the same semantics as > __attribute__((unused)), and cause [[maybe_unused]] applied to a type > to warn about unreferenced variables of that type. The mailing list > thread starting at > > "[[maybe_unused]] classes" discussed this, and argues that those > special semantics of __attribute__((unused)) and [[maybe_unused]] > applied to a type are not actually useful: The GCC documentation > cites as a use case "lock or thread classes, which are usually defined > and then not referenced, but contain constructors and destructors that > have nontrivial bookkeeping functions". But the presence of those > non-trivial con-/destructors will already prevent the compiler from > emitting warnings about seemingly unused variables of such types. So > applying __attribute__((unused)) to such types looks like it does not > bring any additional value. Or what do other people think? Not sure if I quite understand this. If the attribute cannot be used to mark (indirectly) variables of type (say) std::string as worthy of warnings if they are unused, I think these special cases are not useful. The assumption might be that compilers need to suppress warnings for RAII guard variables, but GCC does not warn for them anyway. This is discussed occasionally, and the assumption is that such warnings would not be useful. > * __attribute__((warn_unused_result)) (which can only be applied to > functions) behaves the same as [[nodiscard]] applied to functions. This is not entirely accurate because warn_unused_result is much harder to suppress at the call site (at least in GCC). > * __attribute__((warn_unused)) (which can be applied to class types) > is meant to allow warnings about unreferenced variables of the given > type, where the compiler could otherwise not infer that those > variables are truely unused (because the type has non-trivial > con-/destructors). (This attribute does not have a standard > counterpart.) > > Similarly to how [[nodiscard]] can be applied to individual > constructors, it looks beneficial to me to allow > __attribute__((warn_unused)) to be applied to individual constructors, > too. One example use case is a RAII class that has one constructor > that does not acquire a resource (often the default constructor) and > another constructor that does acquire a resource. So the class itself > cannot be marked __attribute__((warn_unused)). But if the > non-acquiring constructor could individually be marked > __attribute__((warn_unused)), the compiler could warn about > unreferenced variables that are initialized via that constructor. > "Allow > `__attribute__((warn_unused))` on individual constructors" would > implement that for Clang---but was met with some reservation for now, > due to the already somewhat confusing landscape of standard and > GCC/Clang-specific attributes guiding warnings about unused entities > as outlined in this post. What do other people think about it? Would > it be something that GCC would also want to implement? How does this interact with deriving warn_unused for std::vector if T is warn_unused? That seems like a useful feature, and appears to require that this is a type property, not a constructor property. And maybe there is a trend to use constructor functions for these guard variables and auto? So auto g = make_guard(obj); instead of: guard g(obj); Thanks, Florian