[all-commits] [llvm/llvm-project] b3aebb: [CI] Bump python dependencies

Tue Sep 29 02:48:02 PDT 2026

  Branch: refs/heads/release/23.x
  Home:   https://github.com/llvm/llvm-project
  Commit: b3aebbf2de7b92cb6aec89ce4493670a4d1e22b9
      https://github.com/llvm/llvm-project/commit/b3aebbf2de7b92cb6aec89ce4493670a4d1e22b9
  Author: Aiden Grossman <aidengrossman at google.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M .ci/all_requirements.txt
    M mlir/python/requirements.txt

  Log Message:
  -----------
  [CI] Bump python dependencies

Bump CI deps for 23.x specifically. Bumping everything like we did in
main causes some test failures in MLIR due to some changes that happened
there after the 23.x branch was cut.

  Commit: c0f43c82604c9781d55d3e957d57d7b692570ed8
      https://github.com/llvm/llvm-project/commit/c0f43c82604c9781d55d3e957d57d7b692570ed8
  Author: Demetrios Chiuratto Agourakis <demetrios at agourakis.med.br>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
    M llvm/test/CodeGen/X86/llvm.frexp.ll

  Log Message:
  -----------
  [SelectionDAG] Fix result index and vector width in unrollExpandedOp (#225886)

Fixes #224127.

In `DAGTypeLegalizer::WidenVectorResult`, `unrollExpandedOp` computes
the unroll count and widened vector type from the result being legalized
(`ResNo`) rather than unconditionally using result 0. For multi-result
nodes where result types differ (e.g. `ISD::FFREXP`), this prevents
mismatched vector widths and preserves the correct result index from
`DAG.UnrollVectorOp`.

Assisted-by: Claude

---------

Co-authored-by: Demetrios Chiuratto Agourakis <agourakis82 at gmail.com>
(cherry picked from commit 5cab2963e13496c272a482145b11796e9e26eeb4)

  Commit: 9efc50ac8a20e6f8b127a4204943e25eaa6f3313
      https://github.com/llvm/llvm-project/commit/9efc50ac8a20e6f8b127a4204943e25eaa6f3313
  Author: Ryan VanderMeulen <ryanvm at gmail.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M llvm/utils/extract_symbols.py

  Log Message:
  -----------
  [Windows] Don't export clang::interp symbols for plugins (#221295)

With `LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON`, `clang.exe` built from the
23.x release branch exports 66679 symbols on x86_64 Windows, over the
65535 limit of the PE export table, so it no longer links:

```
lld-link: error: too many exported symbols (got 66679, max 65535)
```

For comparison, the same configuration on 22.1.8 exports 65465 symbols,
so the headroom was already almost gone.

`clang::interp`, the constant expression bytecode interpreter, accounts
for roughly 4500 of the exported symbols (counted with `llvm-readobj
--coff-exports` on a linked aarch64 23.1.0 `clang.exe`). Its headers
live in `clang/lib/AST/ByteCode` and are not installed; the only mention
in a public header is the forward declaration of `interp::Context` in
`ASTContext.h`. A plugin cannot call into it, so there is no reason to
keep exporting it. Filtering it out follows the existing
`dump`/`dumpColor`/`printPretty` exclusions in
`should_keep_microsoft_symbol`.

Related: #87865 (open; earlier rounds #60109, #56109). This does not get
the MSVC-with-examples configuration from that issue under the limit by
itself, but it removes the largest block of symbols that can never be
used by a plugin, and is what gets the Firefox clang 23 toolchain
(x86_64-pc-windows-msvc, X86;ARM;AArch64;WebAssembly,
clang+lld+clang-tools-extra) from 66679 to roughly 62100 exports.

---
**AI tool use disclosure** (per the [LLVM AI Tool Use
Policy](https://llvm.org/docs/AIToolPolicy.html)): this change was
developed with Claude Code assisting in the analysis and drafting. The
root cause was established against real 23.1.0 binaries and libraries,
the patch was reviewed and tested by the author in Firefox's CI, and the
author is accountable for and able to answer questions about it. Commits
carry an `Assisted-by:` trailer.

(cherry picked from commit be215a25f00139d68517589d78a79c3aa7a7eb26)

  Commit: 532fa5afbe2b77ae12a8fb79e17645b95c3242c9
      https://github.com/llvm/llvm-project/commit/532fa5afbe2b77ae12a8fb79e17645b95c3242c9
  Author: Nico Weber <thakis at chromium.org>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    A lld/test/MachO/arm64-x1.s
    M llvm/include/llvm/BinaryFormat/MachO.h
    M llvm/include/llvm/TargetParser/Triple.h
    M llvm/include/llvm/TextAPI/Architecture.def
    M llvm/lib/BinaryFormat/MachO.cpp
    M llvm/lib/Object/MachOObjectFile.cpp
    M llvm/lib/TargetParser/Triple.cpp
    M llvm/test/tools/llvm-readobj/MachO/file-headers-arm64.test
    A llvm/test/tools/llvm-readobj/macho-arm64e_x1.test
    M llvm/tools/llvm-objdump/MachODump.cpp
    M llvm/tools/llvm-readobj/MachODumper.cpp
    M llvm/unittests/BinaryFormat/MachOTest.cpp

  Log Message:
  -----------
  [ld64.lld, llvm-otool] Minimal arm64e.x1 support (#222721)

Just enough for `llvm-otool -hv` to dump the cpusubtype, and for
ld64.lld to not reject .tbd files that have an arm64e.x1 slice.

This is needed to link mac binaries against the macOS 27 SDK.

(cherry picked from commit b8007a8e4020b8bca2b12e941660e10bf5bf6716)

  Commit: 8f747d63ffb2b07c6bdb09e220b0ec98d6038921
      https://github.com/llvm/llvm-project/commit/8f747d63ffb2b07c6bdb09e220b0ec98d6038921
  Author: Nico Weber <thakis at chromium.org>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M lldb/include/lldb/Host/SafeMachO.h

  Log Message:
  -----------
  [lldb] Attempt to unbreak building lldb with the 27 SDK (#223090)

See this report:
https://github.com/llvm/llvm-project/pull/222721#issuecomment-5636252813

(cherry picked from commit 923902483c7a6937a65b9679795a247ae2a2ad56)

  Commit: ee66426152f9e7e17f98db4691414ad7cf0c66ea
      https://github.com/llvm/llvm-project/commit/ee66426152f9e7e17f98db4691414ad7cf0c66ea
  Author: Keith Smiley <keithbsmiley at gmail.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M llvm/include/llvm/TargetParser/Triple.h
    M llvm/include/llvm/TextAPI/Architecture.h

  Log Message:
  -----------
  Avoid abi break

  Commit: 6abb6e738b33d2c4b58e35f069f9f9ea4fde432f
      https://github.com/llvm/llvm-project/commit/6abb6e738b33d2c4b58e35f069f9f9ea4fde432f
  Author: Vipul Cariappa <vipulcariappa at gmail.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M clang/include/clang/AST/DeclCXX.h
    M clang/include/clang/AST/Redeclarable.h
    M clang/lib/Interpreter/IncrementalParser.cpp
    A clang/test/Interpreter/failed-input-keeps-redecls.cpp

  Log Message:
  -----------
  [clang-repl] Keep earlier declarations alive when an input fails (#218149)

Fixes #201844

(cherry picked from commit 37e2844bc4681c69f61cbb55376a29ae0445c18c)

  Commit: dfb1297f7c3fdd91d9d690971ab2170fca27eced
      https://github.com/llvm/llvm-project/commit/dfb1297f7c3fdd91d9d690971ab2170fca27eced
  Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
  Date:   2026-09-29 (Tue, 29 Sep 2026)

  Changed paths:
    M clang/include/clang/AST/DeclCXX.h
    M clang/lib/AST/DeclFriend.cpp
    M clang/lib/Sema/SemaLookup.cpp
    A clang/test/Modules/pr218228.cppm

  Log Message:
  -----------
  [C++20] [Modules] Load friends for classes in ADL (#219094)

Close https://github.com/llvm/llvm-project/issues/218228

The root cause of the problem is the corresponding friend is not loaded
at the point of ADL.

This patch tries to fix this simply by loading the friends at the point
of ADL. Note that this may be best efficient if there are a lot of
friends. We just think it is rare. If it is really possible, we can
change the structure of friends from a list to a name lookup table.

(cherry picked from commit 01aedf3b34325ad2f74a77325a2da9a7e36ae3d5)

Compare: https://github.com/llvm/llvm-project/compare/c9376624635f...dfb1297f7c3f

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications