From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754969AbdK2QMR (ORCPT ); Wed, 29 Nov 2017 11:12:17 -0500 Received: from ms.lwn.net ([45.79.88.28]:55902 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753153AbdK2QMQ (ORCPT ); Wed, 29 Nov 2017 11:12:16 -0500 Date: Wed, 29 Nov 2017 09:12:14 -0700 From: Jonathan Corbet To: Will Deacon 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: <20171129091214.32437ea0@lwn.net> In-Reply-To: <1511968805-20651-1-git-send-email-will.deacon@arm.com> References: <1511968805-20651-1-git-send-email-will.deacon@arm.com> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. jon