Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23

[Peter Zijlstra]

On Thu, May 28, 2026 at 11:12:42AM +0200, Niklas Cassel wrote:
> On Wed, May 20, 2026 at 08:28:08AM -0000, tip-bot2 for Marco Elver wrote:
> > The following commit has been merged into the locking/core branch of tip:
> > 
> > Commit-ID:     2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> > Gitweb:        https://git.kernel.org/tip/2422e2b10ebb45a6ac7a799a36462bfda3eda4c5
> > Author:        Marco Elver <elver@xxxxxxxxxx>
> > AuthorDate:    Fri, 15 May 2026 14:43:31 +02:00
> > Committer:     Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > CommitterDate: Tue, 19 May 2026 13:49:01 +02:00
> > 
> > compiler-context-analysis: Bump required Clang version to 23
> > 
> > Clang 23 introduces several major improvements:
> > 
> > 1. Support for multiple arguments in the `guarded_by` and
> >    `pt_guarded_by` attributes [1]. This allows defining variables
> >    protected by multiple context locks, where read access requires
> >    holding at least one lock (shared or exclusive), and write access
> >    requires holding all of them exclusively.
> > 
> > 2. Function pointer support [2]. We can now add attributes to function
> >    pointers just like we do on normal functions.
> > 
> > 3. A fix to use arrays of locks [3]. Each index is now correctly treated
> >    as a separate lock instance.
> > 
> > 4. A fix for implicit member access in attributes [4]. This allows to
> >    use __guarded_by(&foo->lock) correctly.
> > 
> > Overall that makes it worthwhile bumping the compiler version instead of
> > trying to make both Clang 22 and later work while supporting these new
> > features.
> > 
> > Signed-off-by: Marco Elver <elver@xxxxxxxxxx>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > Reviewed-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> > Reviewed-by: Bart Van Assche <bvanassche@xxxxxxx>
> > Link: https://github.com/llvm/llvm-project/pull/186838 [1]
> > Link: https://github.com/llvm/llvm-project/pull/191187 [2]
> > Link: https://github.com/llvm/llvm-project/pull/148551 [3]
> > Link: https://github.com/llvm/llvm-project/pull/194457 [4]
> > Link: https://patch.msgid.link/20260515124426.2227783-1-elver@xxxxxxxxxx
> > ---
> 
> Hello Peter,
> 
> I can see that this has been queued up on branch: locking/core
> 
> However, this branch also has a bunch of other stuff queued up on it.
> 
> 
> I would like to queue up a libata patch that requires this patch for
> kernel 7.2 in the libata tree:
> https://lore.kernel.org/linux-ide/7ce6e1f0-6c65-439f-9a34-92bc5e977cce@xxxxxxx/T/#t
> 
> (Without the patch in $subject, implicit member access in attributes does not
> work, and the above libata patch would result in build errors on clang 22.)

Yeah, I reported that to Marco a while ago; sadly I did not yet get
around to trying to fix the patch I had with a fresh clang :/

> Would it be possible for you to provide an immutable branch with only
> this specific commit, such that I could merge that immutable branch to
> libata/for-next (such that we carry the exact same SHA1) in both trees?

I think that means I have to rebase tip/locking/core; pull out that
patch and stick it in a separate branch and then merge the two branches,
right? Git and me never really get along well.

Let me see if I can do this without destroying stuff :-)