Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Yao Zi <ziyao@disroot.org>]

On Mon, Apr 28, 2025 at 08:49:43AM -0600, Tom Rini wrote:
> On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote:
> > On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> > > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > > > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > > > >be ignored with warnings like,
> > > > > >
> > > > > 
> > > > > 
> > > > > Do you have an example for reprocing the issue?
> > > > 
> > > > Sure,
> > > > 
> > > > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > > > 		configs/starfive_visionfive2_defconfig
> > > > 
> > > > or a smaller example for demonstrating the behaviour,
> > > > 
> > > > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > > > 	# comment line
> > > > 	normal line
> > > > 	EOF
> > > > 
> > > > and you could see the strange indentation. For reproducing the exact
> > > > Kconfig warnings,
> > > > 
> > > > 	make ARCH=riscv \
> > > > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > > > 		starfive_visionfive2_defconfig
> > > > 
> > > > (Clang is called clang-19 on my machine)
> > > > 
> > > > > Is there an understanding why Clang behaves in this way?
> > > > 
> > > > Sadly I have no idea. I guess it may serve for improving
> > > > human-readability of the preprocessed output.
> > > 
> > > This is https://github.com/llvm/llvm-project/issues/78778
> > 
> > Thanks for the reference! I did a quick search among LLVM's issues
> > before sending the patch but didn't find anything useful.
> > 
> > Do you think such workaround is acceptable? It seems the link should be
> > included in commit message as well.
> 
> I'd like to see if we can get llvm to fix this moving forward first. Can
> you please comment on the issue as you're hitting this now too?

Sure it should be fixed in LLVM and I've left a comment in the issue.

But even though it's fixed in upstream, it will be nice to have such
compatibility workarounds for some time to keep compatibile with older
Clang toolchains, about which my concern is most.

> -- 
> Tom

Best regards,
Yao Zi