Re: [PATCH v2] docs: kconfig: fix shell function syntax in caveats

[Nicolas Schier]

On Tue, Sep 15, 2026 at 03:02:04PM -0700, Nathan Chancellor wrote:
> On Tue, Sep 15, 2026 at 12:59:40PM +0200, Nicolas Schier wrote:
> > On Mon, Sep 07, 2026 at 01:37:37PM +0300, Erkan Erdem wrote:
> > > Kconfig separates a function name from its arguments with a comma, but
> > > the caveats section uses Make-style whitespace in its shell calls.
> > > These expressions expand as undefined variables rather than invoking
> > > the shell function, so the supposedly working CC_HAS_ENDIAN_FLAG
> > > example fails to parse.
> > > 
> > > Add the missing commas to the shell calls in this section. Keep the
> > > Make examples unchanged.
> > > 
> > > Fixes: 316d55d55f49 ("Documentation: kconfig: document a new Kconfig macro language")
> > > Assisted-by: LLM
> > > Signed-off-by: Erkan Erdem <hexvalid@xxxxxxxxx>
> > > ---
> > > 
> > > Changes in v2, addressing Julian Braha's review:
> > > - Remove whitespace after the comma in the three remaining shell calls.
> > > 
> > > v1: https://lore.kernel.org/all/20260905124045.42713-1-hexvalid@xxxxxxxxx/
> > > 
> > > The issue, patch and changelog were prepared with an AI coding assistant.
> > > The assistant also prepared the v2 revision and ran the checks below.
> > > 
> > > Validation:
> > > - Re-ran the documented working CC_HAS_ENDIAN_FLAG example using the
> > >   Kconfig conf tool built with Clang on macOS. With a test helper returning
> > >   y for either endian flag, the original example fails to parse; v2
> > >   executes both probes and sets CC_HAS_ENDIAN_FLAG=y for both endiannesses.
> > > - Rebuilt the changed page alone with Sphinx, treating warnings as errors.
> > > - The complete kernel documentation set and kernel were not built.
> > > 
> > >  Documentation/kbuild/kconfig-macro-language.rst | 8 ++++----
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > 
> > Thanks!  I'll queue it for kbuild-fixes, but it might be defered to v7.4 
> > if no other build relevant fix will pop-up.
> 
> I am not opposed to this going via -fixes but given that it is just
> documentation examples and there do not appear to be any problematic
> instances in tree, I feel like this could very reasonably go through
> -next. 316d55d55f49 is from 4.18, so the examples have been wrong for a
> long time. With that, I would probably not classify it as urgent.

Ack.  I remove the patch from kbuild-fixes-unstable again, thanks.


-- 
Nicolas