From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933348AbdK2QfB (ORCPT ); Wed, 29 Nov 2017 11:35:01 -0500 Received: from foss.arm.com ([217.140.101.70]:41340 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbdK2QfA (ORCPT ); Wed, 29 Nov 2017 11:35:00 -0500 Date: Wed, 29 Nov 2017 16:35:03 +0000 From: Will Deacon To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, mawilcox@microsoft.com Subject: Re: [PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none Message-ID: <20171129163502.GB32356@arm.com> References: <1511968805-20651-1-git-send-email-will.deacon@arm.com> <20171129091214.32437ea0@lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129091214.32437ea0@lwn.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2017 at 09:12:14AM -0700, Jonathan Corbet wrote: > On Wed, 29 Nov 2017 15:20:03 +0000 > Will Deacon wrote: > > > My bisect scripts starting running into build failures when trying to > > compile 4.15-rc1 with the builds failing with things like: > > > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! > > > > The line in question is actually just a #define, but after some digging > > it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea > > ("Add optional check for bad kernel-doc comments") that results in > > kernel-doc running on each source file. The file in question has a > > badly formatted comment immediately before the #define: > > > > /** > > * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for > > * bus layer usage. > > */ > > > > which causes the regex in dump_struct to fail (lack of braces following > > struct declaration) and kernel-doc returns 1, which causes the build > > to fail. > > > > Fix the issue by always returning 0 from kernel-doc when invoked with > > -none. It successfully generates no documentation, and prints out any > > issues. > > That seems like a worthy fix. I can take this one and ship it up with a > few other docs fixes in the near future, thanks. Brill, cheers Jon. It had me extremely confused for a while until I figured out the warning wasn't coming from GCC :) Will