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 ABBAC3858D3C for ; Wed, 26 Apr 2023 22:03:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABBAC3858D3C 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=1682546621; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=HZiavfeFax9sRZbed7ZJvBpEbXJHuEMAI0wOxookDH8=; b=SxVYQTqqWBOA55Dvfi7+Lj1N4WG4XTeBFphiOH5+Q2BqMABjwnODLej8jaJPdK476ntrG7 6jTtY8erzOe5jj/m5dSZWCPmApu3bQEI/CJnWhj8VU3rdV/zb0xXic1DHgg4ijb0w3Me1h DfiHiZGEPLiENbZZ3Cp/BAo275ZdHEY= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-175-2wE5pXyBMtiqXeMTfxj0ZA-1; Wed, 26 Apr 2023 18:03:39 -0400 X-MC-Unique: 2wE5pXyBMtiqXeMTfxj0ZA-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-953429dac27so697462266b.0 for ; Wed, 26 Apr 2023 15:03:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682546618; x=1685138618; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HZiavfeFax9sRZbed7ZJvBpEbXJHuEMAI0wOxookDH8=; b=hrfCZjNOaYV1+89XaPob0SHOozarJOe0JvMgpCLMQ7vLg+nIIqQl0CcLmftrS+IT0f 79hxNweWG6vslHcQA7/xrs1efyqLukmaQGUW8VX/neFkN5NtMDKgy8xos9b+91MFFmfH FfuT1L7j7AN60vddrYrRAhPl11i/IYWtcVQHN+mBQIclLvewsKvcDLD6PVu2ih8uhKxh qnklhrwOWL7m0AaXmgdigQVMZGxiD/FUmsQjk4eMdQIkwmr81iuJ7E39xBO5aNnpudLW fyvH8lQMW0D3RcLNuIqP+ATTxi7HTjXNjD+sThBNYvT0UbBBWVoCJwddLcDCnDuLdFtH 2FDg== X-Gm-Message-State: AAQBX9f2n9sWhmhuNZQ9JBHgPydTp5UbLlgtM+Dj/8F6IoVIKVYBv/qj s5KKbEpyhW5p7xCP1XJxTcbOMS9ttlryNGfemhDgKz9mw8bM4DCliWNlwkPwA6cpsCmNI0IU3JF oPVkMDU28u19pI/k226vuud8ddNfcMBH3Ao99QNfdkotNBuy8XqhLarivhmfZBoUb1/g= X-Received: by 2002:a17:906:2897:b0:94e:e092:6eda with SMTP id o23-20020a170906289700b0094ee0926edamr18510263ejd.53.1682546618203; Wed, 26 Apr 2023 15:03:38 -0700 (PDT) X-Google-Smtp-Source: AKy350bYlZ+YpABhPLr8XwbwO+2zVP1wLZGi/ZPLmPScneJRRMnDZAmxpjSvMYRu9OpRVl7cDgo0ag== X-Received: by 2002:a17:906:2897:b0:94e:e092:6eda with SMTP id o23-20020a170906289700b0094ee0926edamr18510242ejd.53.1682546617830; Wed, 26 Apr 2023 15:03:37 -0700 (PDT) Received: from [192.168.178.30] (i59F6C41.versanet.de. [89.246.196.1]) by smtp.gmail.com with ESMTPSA id g25-20020a170906349900b0095336e8e012sm8874084ejb.176.2023.04.26.15.03.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Apr 2023 15:03:37 -0700 (PDT) Message-ID: Date: Thu, 27 Apr 2023 00:03:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: gcc@gcc.gnu.org, clang@discourse.llvm.org From: Stephan Bergmann Subject: GCC/Clang attributes guiding warnings about unused entities X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 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: [cross-posting this to both the GCC and Clang communities] I have two specific issues on the subject I would like to discuss below. But first a quick overview: C++ has two attributes dealing with warnings about unused entities: * In one direction (making the compiler suppress warnings it would otherwise emit), [[maybe_unused]] (which can be used on lots of different kinds of entities) is meant to suppress warnings about otherwise unused entities. * In the other direction (making the compiler emit more warnings than it could otherwise infer), [[nodiscard]] (which can be used on certain types, functions, and constructors) is meant to cause warnings about discarded results of function calls or constructor invocations. (For a [[nodiscard]] type, it warns about discarded results of calls to functions returning that type. For a [[nodiscard]] function, it warns about discarded results of calls to that function. For a [[nodiscard]] constructor, it warns about discarded objects initialized via that constructor.) GCC and (through its GCC compatibility) Clang have three additional non-standard attributes: * __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? * __attribute__((warn_unused_result)) (which can only be applied to functions) behaves the same as [[nodiscard]] applied to functions. * __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?