From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 009A83899073 for ; Tue, 25 May 2021 15:48:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 009A83899073 Received: by mail-ot1-x331.google.com with SMTP id v19-20020a0568301413b0290304f00e3d88so29013505otp.4 for ; Tue, 25 May 2021 08:48:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Do/yahfaha9xRM5SSDf3yyrMWlGQt3IUtzVxEkzBeU0=; b=EjK5cqNAoCD3LjeyWWxbEP7OEeLush7gyA8wB26l6glcZI5K0NYnbWYbwnVrUdi+iD y7R3H1FkrydmYUahqJQ+NSa0wQhN5McoSRKvM16inNwciy6Y+Co0NvYNGeuNLZnnP/xg LLIzG4old/fsdZ/yzgLCQAoyj+Ql6kOCQPtQ0z9751kPLsfxlOQmUklwvT+7dbDsyQFW Yv2XZGbvJ0sZZtDRmWL8HTnqmDBlPFPkl49klQbpXrbQeu8zKofmBUa36AgUn9RE8Hwb /sr2eD3zIPUspFn0lQQrosS7e7bwsYSu4Yqar+/Gkw+Iptd+muXhNtZwARPWkG+1YZOR /Gqw== X-Gm-Message-State: AOAM533eJ/WHGT+QSiMQkQ0BnNzsbnynet10/jVCnByM7uHTMVRZDRaz 1X3A8bwDx3a4cF14A8H7CaMcsiC/M+I= X-Google-Smtp-Source: ABdhPJxGmh7JH+H2Qaw0RCLvxTc0uMuPmAoexQVMIvQhkXZnNrcTTtSTB9uRB/YeE21o/4Jeo2ltBA== X-Received: by 2002:a05:6830:31ac:: with SMTP id q12mr23919101ots.348.1621957701133; Tue, 25 May 2021 08:48:21 -0700 (PDT) Received: from [192.168.0.41] (174-16-126-108.hlrn.qwest.net. [174.16.126.108]) by smtp.gmail.com with ESMTPSA id 19sm3229063oiy.11.2021.05.25.08.48.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 08:48:20 -0700 (PDT) Subject: Re: [PATCH 8/11] use xxx_no_warning APIs in Objective-C To: Iain Sandoe , Martin Sebor Cc: gcc-patches References: <92db3776-af59-fa20-483b-aa67b17d0751@gmail.com> <535d1b55-fc0a-63c3-08b5-48a017674d1e@gmail.com> <1e93eb13-f5f9-1029-4d91-d685cc05ce6a@redhat.com> <2C4CF4F9-7B9D-4AF6-9128-A8020C2A2135@googlemail.com> From: Martin Sebor Message-ID: Date: Tue, 25 May 2021 09:48:19 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <2C4CF4F9-7B9D-4AF6-9128-A8020C2A2135@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 15:48:23 -0000 On 5/25/21 8:01 AM, Iain Sandoe via Gcc-patches wrote: > Hi Martin > > Martin Sebor via Gcc-patches wrote: > >> The attached patch replaces the uses of TREE_NO_WARNING in >> the Objective-C front end. >> > > I’ve been gradually trying to improve/add locations in the ObjC stuff. > > To that end, I wonder if it might be worth considering always supplying > the intended masked warning (rather than omitting this when the node > currently has no location).  I guess that would mean that the setter/getter > would need to determine if there was some suitable location (more work > but better abstraction). > > This would mean that an improvement/addition to location would > automatically > gain the improvement in masked warnings. > > This is not an objection (the patch is OK for ObjC as is) .. just a > question, I'm not sure I understand correctly. Let me try to clarify: The calls to the {get,set}_no_warning() with no option introduced by the patch are of two kinds: one where the intent is to query or suppress all warnings for an expression (or a DECL, like a synthesized artificial temporary), and another where it's not apparent from the code which warning is meant to be queried or suppressed. I think all the ones in the ObjC front end are of the latter sort. (None of these calls are due to the location being unknown.) With that, if you are suggesting to try to find the suitable option to pass to the latter kind of calls above, I agree. If you have ideas for what those might be I can give them a try. Looking at the ObjC suppression code again, all the set_no_warning() calls with no option are for what looks like synthesized types, so maybe that's a clue: could -Wunused be the warning we want to suppress there? Martin > > thanks > Iain >