All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH] parse: warn on trailing whitespace after line continuation backslash
Date: Tue, 4 Aug 2026 14:15:51 +0200	[thread overview]
Message-ID: <30ef1b6c-cdce-42e9-8bc8-c94c67fa5b68@est.tech> (raw)
In-Reply-To: <34211867d74a9757b5b0ff10e7ac3c0b4811ceda.camel@linuxfoundation.org>


On 2026-08-04 13:37, Richard Purdie wrote:
> On Tue, 2026-08-04 at 12:37 +0200, Jaipaul Cheernam wrote:
>>    Hi Richard,
>>
>>     Fair point — it doesn't break parsing itself and the code churn is
>> larger than ideal for a warning.
>>
>>     Would you prefer if I just submitted the oe-core fixes to clean up
>> the affected recipes instead and dropped this bitbake change? That
>> solves the immediate problem without adding complexity to the parser.
> You should definitely send that clean up for oe-core.
   Hi Richard,

   Thanks for the detailed feedback.

I will send a clean-up patch.

> I was toying with the idea we just make whitespace after a line break
> character a fatal parsing error. Most of the fatal errors are inside
> feeder() rather than where you changed the code.
  That would be the cleanest long-term. A fatal error for whitespace 
after \ makes sense since the backslash must be the last character — 
anything after it is always wrong.
> I then looked at the code further and it isn't just trailing whitespace
> after "\" that is an issue. For example, after "}" closing a function
> could also be an issue in the same way. I didn't look in detail beyond
> that, there will be further similar issues though and that does mean
> your patch is incomplete :/.
  Good point, I hadn't considered that.
>>    Alternatively, I could reduce this to a bb.note() (debug-level) so
>> it's only visible with -v, keeping it minimal.
> I think this needs further thought and some wider testing of how
> widespread trailing whitespace is.
>
> We might just want to make any trailing spaces a warning since we
> currently just swallow and hide it unconditionally?
I tried this — warned on any trailing whitespace in all parsed lines 
(comparing raw line minus newline against rstrip'd version). Running 
core-image-minimal:

   - 1665 total warnings (due to repeated re-parse of same files)
   - 59 unique (distinct file:line)
   - 31 files affected (.bbclass, .bb, .inc, .conf)

Most are in bbclass files like sanity.bbclass, buildstats.bbclass, 
useradd.bbclass, kernel-yocto.bbclass, libc-package.bbclass etc. The 
duplication from re-parsing makes it noisy without some form of dedup.

A few options for v2:

  1. Keep it narrow — only warn after \ and } (the cases that actually 
cause patch conflicts). Around 10 unique warnings.
  2. Warn on everything but with dedup (a module-level set). Cleaner 
output but adds state to the parser.
  3. Warn on everything and send a cleanup series fixing all 59 
instances in oe-core. Then the warning stays as a guard for future 
submissions.

What would you prefer?


Thanks,

Jaipaul


>
> Cheers,
>
> Richard
>


  reply	other threads:[~2026-08-04 12:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  9:08 [PATCH] parse: warn on trailing whitespace after line continuation backslash Jaipaul Cheernam
2026-08-04 10:27 ` [bitbake-devel] " Richard Purdie
2026-08-04 10:37   ` Jaipaul Cheernam
2026-08-04 11:37     ` Richard Purdie
2026-08-04 12:15       ` Jaipaul Cheernam [this message]
2026-08-06 10:44 ` [PATCH v2] parse: warn on trailing whitespace in parsed lines Jaipaul Cheernam
2026-08-06 11:24 ` Jaipaul Cheernam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30ef1b6c-cdce-42e9-8bc8-c94c67fa5b68@est.tech \
    --to=jaipaul.cheernam@est.tech \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.