Update ROOT and Cling to LLVM22 by devajithvs · Pull Request #21658 · root-project/root

devajithvs · 2026-03-23T13:08:53Z

This Pull request:

This is a draft PR. Some tests are expected to fail.

We need LLVM22 support for the following before we can merge this:

CLAD
CppInterOp
AdaptiveCpp (Full LLVM22 support doesn't exist upstream yet, disable this now to not block the upgrade).

TODO:

Fix failing tests.
Squash and reorganize commits.
Separate PR for changes that can go independent of the upgrade.
Fix FIXME and temporary commits

Changes or fixes:

Checklist:

tested changes locally
updated the docs (if necessary)

This PR fixes #

github-actions · 2026-03-23T14:29:24Z

Test Results

23 files 23 suites 3d 19h 47m 28s ⏱️
3 866 tests 3 829 ✅ 0 💤 37 ❌
78 765 runs 78 507 ✅ 221 💤 37 ❌

For more details on these failures, see this check.

Results for commit a80f916.

♻️ This comment has been updated with latest results.

ferdymercury · 2026-03-23T17:19:05Z

AdaptiveCpp - potentially

Related: AdaptiveCpp/AdaptiveCpp#1986

mcbarton · 2026-03-23T20:42:17Z

Here is the PR I have updating CppInterOp to llvm 22 compiler-research/CppInterOp#812 . It builds with llvm 22 (tested through the ci with upstream llvm 22 and clang-repl), but several tests currently fail. Unsure how the patch would fair with roots llvm 22 and cling.

This fixes dictionary generation for ROOT types such as ROOT::Math::IParametricFunctionMultiDimTempl<double> (exposed as IModelFunction via a typedef chain), where the missing prefix caused incorrect class names in the generated dictionary. This is needed after the nested name specifier changes in LLVM22.

Fix tests: - pyunittests-bindings-pyroot-cppyy-cppyy-test-advancedcpp - root-io-newstl-run

… in LLVM22 LLVM22 removed ElaboratedType from the Clang type system and moved NestedNameSpecifier directly into RecordType. In LLVM20, ElaboratedType::desugar() stripped the global qualifier, and we get "Object" from "::Object". In LLVM22 this ElaboratedType no longer exists, prefix is stored directly causing RecordType nodes to retain the global namespace prefix. We try to restore the previous partial-desugaring behavior by explicitly detecting RecordType instances with a global NestedNameSpecifier and reconstructing the underlying canonical declaration type. Only the global namespace ("::") is stripped; user-defined namespaces ("std::", "NS::") are preserved.

ElaboratedType was completely removed in LLVM22 There is no equivalent equivalent way to replace it with. getPrefix() was used as a drop-in replacement for the `ElaboratedType` during the rebase, this was wrong and not really needed. This caused types accessed via 'using namespace' to enter code paths that were never taken in LLVM20. Without this fix rootcling fails with: ``` Error in <CloseStreamerInfoROOTFile>: Cannot find enum ROOT::Math::Integration::Type. ``` Where ROOT::Math::Integration::Type is resolved from a using namespace

…o standard types TODO: This fixed macos failure. Need to look into this more. Ref: llvm/llvm-project@7c402b8

… removal This will fix gtest-tree-ntuple-ntuple-type-name, that was failing prior to this commit. We probably need to revisit this and find a better/generalized way to handle all similar cases. Fix for cppyy-test-pythonization

The Transform.C test was constructing a bare Transform::Config that did not populate m_toReplace, so the basic_string<char> to std::string substitution could not fire during partial desugaring, causing the test to produce "std::pair<const std::basic_string<char>, int>" instead of the expected "std::pair<const std::string, int>". Mirror what TNormalizedCtxImpl does: look up std::string, take its canonical type pointer as the key, and insert the typedef type as the replacement value in m_toReplace.

Prior to LLVM22, GetNormalizedName would strip Class keyword from nested template arguments as a side-effect of ElaboratedType desugaring. This was accidental erasure of user-written syntax. In LLVM22, ElaboratedType was removed and the keyword is stored directly on TagType. The normalization code no longer strips it, so the output now reflects what the user wrote:

The change in getFullyQualifiedType() in the commit llvm/llvm-project@af27466 added explicit desugaring of UsingType: ``` if (isa<UsingType>(QT.getTypePtr())) { return getFullyQualifiedType(QT.getSingleStepDesugaredType(Ctx), Ctx, WithGlobalNsPrefix); } ``` This has been there since LLVM14 and we could disentagle this from the upgrade. This causes `SG::sgkey_t` to be resolved to its underlying type `uint32_t` when GetFullTypeName() is called, rather than preserving the typedef alias name as before. For now, update the test expectation to reflect the new behavior or move this to a separate PR.

Unmark xfail for test14_templated_return_type

…ePaths CopyIncludePaths assumed that a framework entry always implies `Group==Angled` and called `report_fatal_error` for any other group. This changed after LLVM commit: llvm/llvm-project@515b4a4 Framework entries land in UserEntries with `IsFramework=true` and `Group=frontend::System` and cling fails on macos with "Invalid option set!" Fix by also allowing `Group=frontend::System` for framework entries. See compiler-research/CppInterOp#672 (comment)

LLVM22 introduced UnsubstitutedConstraintSatisfactionCache: llvm/llvm-project@e9972de This causes some stale results to persist across transactions For example, evaluating is_default_constructible_v<Inner<int>> for an incomplete Inner<int> caches the 'false' value here. Completing Inner<int> in the next transaction will see the cached 'false' instead of re-evaluating. There is a TODO in clang to make this a private member, so this solution is not ideal. This might not be the right fix, clang and clang-repl also fails for the below, maybe we should just update the test-case `roottest-root-meta-ROOT-7462-Test` to prevent this condition (gcc14 and above). Minimal reproducer: ``` template <typename T> struct X; // Forward declaration template <typename T> struct S { S() requires std::is_default_constructible_v<T> = default;}; bool b = std::is_default_constructible_v<S<X<int>>>; template <> struct X<int> {}; // Complete the definition of X<int> S<X<int>> s; // Fails without this patch ``` In ROOT: ``` { gInterpreter->Declare(R"( #include <type_traits> template <typename T> struct X; template <typename T> struct S { S() requires std::is_default_constructible_v<T> = default;}; )"); gInterpreter->Declare("bool b = std::is_default_constructible_v<S<X<int>>>;"); gInterpreter->Declare("template <> struct X<int> {};"); bool ok = gInterpreter->Declare("S<X<int>> s;"); printf("%s\n", ok ? "PASS" : "FAIL"); } ```

LLVM21 implements CWG2369 ("Ordering between constraints and substitution", llvm/llvm-project@e04e140 This moves constraint checking before full template argument substitution. Alias templates may be expanded eagerly during parameter type substitution, causing hard diagnostics to be emitted for substitution failures that are expected and handled by InstantiateTemplateWithDefaults(). Use SFINAETrap so that substitution failures are treated as silent failures, matching the previous behaviour. Fix the remaining failing `pyunittests` on macos: - pyunittests-bindings-distrdf-backend-distrdf-unit-backend-dist - pyunittests-bindings-distrdf-backend-distrdf-unit-backend-graph-caching - pyunittests-bindings-pyroot-cppyy-cppyy-test-cpp11features - pyunittests-bindings-pyroot-pythonizations-pyroot-roofit - pyunittests-io-io-rfile-py - pyunittests-tree-dataframe-dataframe-merge-results - pyunittests-tree-ntuple-ntuple-py-basics - pyunittests-tree-ntuple-ntuple-py-model

AdaptiveCpp does not support LLVM22 yet, there is a PR open, still need some work to get this building with static LLVM, adaptiveCpp is designed to be used as a clang plugin using libLLVM.so, for now, disable this so that this does not become a blocker for LLVM22 upgrade.

Clad support for LLVM22 hasn't been released yet. Temporarily turn this off for CI.

We need to keep siphash folder after the llvm commit: llvm/llvm-project@7f3afab9

We also need to update after the changes in: llvm/llvm-project@88b77073

devajithvs · 2026-07-02T12:35:19Z

@vgvassilev, would you have an idea why clad build on windows is failing here?


cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\lib\Differentiator\cladDifferentiator.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\tools\cladPlugin.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Microsoft\VC\v180\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-mkdir.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-download.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-update.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-patch.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-configure.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-build.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-install.rule;C:\ROOT-CI\build\CMakeFiles\cf0c9c103a9368f09347bf3068b16817\clad-complete.rule;C:\ROOT-CI\build\CMakeFiles\12f73b81bb94717129353e988fa63fe5\clad.rule;C:\ROOT-CI\src\interpreter\cling\tools\plugins\clad\CMakeLists.txt' exited with code 1. [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
      20 Warning(s)
      3 Error(s)

Is that still an issue?

Seems like it is still the case. I am debugging this on a local windows machine I have.

EDIT: This should fix the windows build issue: vgvassilev/clad#1867

Since LLVM12, suppressing inline and anonymous namespaces were separated into distinct flags: - SuppressUnwrittenScope: suppresses anonymous namespaces - SuppressInlineNamespace: suppresses redundant inline namespaces See: llvm/llvm-project@5f12f4ff Add `SuppressUnwrittenScope = true` to strip anonymous namespace prefixes Without this, types in anonymous namespaces are printed as '::(anonymous namespace)::EvNavHandler' which is invalid C++ and causes compilation failures in rootcling-generated dictionary code as seen when building dd4hep against ROOT LLVM22. We were relying on `SuppressScope` which was removed in LLVM22. Also update the Transform.C test to reflect the corrected output

smuzaffar · 2026-07-03T14:40:08Z

cmssw tests passed cms-sw#233 (comment)

devajithvs self-assigned this Mar 23, 2026

devajithvs added skip code analysis Skip the code analysis CI steps for this PR, including verifying clang-formatting and running Ruff. clean build Ask CI to do non-incremental build on PR labels Mar 23, 2026

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 255c7e6 to cfd796b Compare March 23, 2026 13:19

devajithvs force-pushed the ROOT-llvm22 branch from cfd796b to dbf8c51 Compare March 23, 2026 17:04

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 7738727 to d68c1c7 Compare March 24, 2026 09:28

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 7640bdc to 8920b0a Compare March 31, 2026 14:12

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 88b794b to 6284651 Compare April 20, 2026 12:45

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 8d87ccb to 1aa5aae Compare May 4, 2026 07:44

devajithvs force-pushed the ROOT-llvm22 branch from 9561d89 to 0401759 Compare May 13, 2026 08:13

devajithvs force-pushed the ROOT-llvm22 branch from 3e8a41d to 271d3a7 Compare May 21, 2026 09:23

devajithvs force-pushed the ROOT-llvm22 branch 3 times, most recently from 69156a4 to 8f2e30f Compare June 15, 2026 16:29

devajithvs mentioned this pull request Jun 16, 2026

[cling] Pre LLVM22 changes that can go before the actual upgrade #22616

Merged

devajithvs force-pushed the ROOT-llvm22 branch 7 times, most recently from c7b7cf3 to 45543a0 Compare June 24, 2026 11:55

devajithvs added 19 commits July 2, 2026 09:31

[cling][AST] Strip unnecessary global '::' qualifier for TemplateNames

a08938b

Fix tests: - pyunittests-bindings-pyroot-cppyy-cppyy-test-advancedcpp - root-io-newstl-run

[TClassEdit][REVISIT] Map __size_t and __ptrdiff_t aliases back t…

16a6bf1

…o standard types TODO: This fixed macos failure. Need to look into this more. Ref: llvm/llvm-project@7c402b8

[cling][test] Update output print types

e655e4d

[roottest] Update reference files after LLVM22

f818887

[cppyy] Unmark xfail, this test now passes with LLVM22

e641648

Unmark xfail for test14_templated_return_type

[cling] Enable SuppressTagKeywordInAnonNames by default

2df3d0e

[clad] Disable clad temporarily

db758f6

Clad support for LLVM22 hasn't been released yet. Temporarily turn this off for CI.

[CI][llvm-project] Only compare what is already there in third-party

095ecae

We need to keep siphash folder after the llvm commit: llvm/llvm-project@7f3afab9

devajithvs force-pushed the ROOT-llvm22 branch from 0836c20 to 80f8603 Compare July 2, 2026 07:32

Update clad cmake

b7686e3

devajithvs force-pushed the ROOT-llvm22 branch from 8e3b026 to b7686e3 Compare July 2, 2026 09:46

devajithvs closed this Jul 2, 2026

devajithvs reopened this Jul 2, 2026

[interpreter] Update CLANG_CMAKE_DIR after LLVM22 update

8701053

We also need to update after the changes in: llvm/llvm-project@88b77073

devajithvs force-pushed the ROOT-llvm22 branch from 5030dd8 to a80f916 Compare July 3, 2026 09:15

devajithvs mentioned this pull request Jul 3, 2026

[cling] Use SuppressUnwrittenScope to strip anonymous namespace names #22753

Open

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update ROOT and Cling to LLVM22#21658

Update ROOT and Cling to LLVM22#21658
devajithvs wants to merge 32 commits into
root-project:masterfrom
devajithvs:ROOT-llvm22

devajithvs commented Mar 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Mar 23, 2026 •

edited

Loading

Uh oh!

ferdymercury commented Mar 23, 2026

Uh oh!

mcbarton commented Mar 23, 2026

Uh oh!

devajithvs commented Jul 2, 2026 •

edited

Loading

Uh oh!

smuzaffar commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

devajithvs commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This Pull request:

Changes or fixes:

Checklist:

Uh oh!

github-actions Bot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

ferdymercury commented Mar 23, 2026

Uh oh!

mcbarton commented Mar 23, 2026

Uh oh!

devajithvs commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

smuzaffar commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

devajithvs commented Mar 23, 2026 •

edited

Loading

github-actions Bot commented Mar 23, 2026 •

edited

Loading

devajithvs commented Jul 2, 2026 •

edited

Loading