Update ROOT and Cling to LLVM22#21658
Draft
devajithvs wants to merge 37 commits into
Draft
Conversation
devajithvs
added
skip code analysis
devajithvs
force-pushed
the
ROOT-llvm22
branch
2 times, most recently
from
255c7e6 to
cfd796b
Compare
Test Results 21 files 21 suites 3d 9h 10m 28s ⏱️ For more details on these failures, see this check. Results for commit 69156a4. ♻️ This comment has been updated with latest results. |
Collaborator
Related: AdaptiveCpp/AdaptiveCpp#1986 |
|
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. |
devajithvs
force-pushed
the
ROOT-llvm22
branch
2 times, most recently
from
7738727 to
d68c1c7
Compare
devajithvs
force-pushed
the
ROOT-llvm22
branch
2 times, most recently
from
7640bdc to
8920b0a
Compare
devajithvs
force-pushed
the
ROOT-llvm22
branch
2 times, most recently
from
88b794b to
6284651
Compare
devajithvs
force-pushed
the
ROOT-llvm22
branch
2 times, most recently
from
8d87ccb to
1aa5aae
Compare
…havior When entering a submodule, LLVM22 changed the default to hide its exports Currently -Druntime_cxxmodules=ON will fail with a bunch of redefinition errors without this. Ref: llvm/llvm-project@4bb04d4
…pe path LLVM's behaviour may be right: Explicitly-written keywords should be preserved. It is simpler to have this downstream patch than handle all the cases in ROOT/Cling manually. Fix the failing tests on Windows: - roottest-root-io-withoutDictionaries-IOWithoutDictionaries - roottest-root-io-withoutDictionaries-RowWiseNoProxyWarning - roottest-root-tree-stl-mixingInterp - roottest-root-tree-stl-mixingCompiled Need to revisit previous commits added to fix this issue.
Explicitly define ROOT::Math::Integration::Type with a using declaration. In LLVM 22, the existing using namespace directive no longer implicitly resolves these types during dictionary generation, causing rootcling to fail with: ``` Error in <CloseStreamerInfoROOTFile>: Cannot find enum ROOT::Math::Integration::Type. ```
- Update headers and enums - Use options library - llvm/llvm-project@f63d33d - Do not share ownership of HeaderSearchOptions - llvm/llvm-project@77148fc - Update function signatures for Sema::*InstantiationScope - llvm/llvm-project@c1468e9 - API Changes related to InfosShard - llvm/llvm-project@cd269fe - Use IdentifierLoc - llvm/llvm-project@d83b639 - Add isInjectedClassName - StringSet API update - Update function signatures - getDependentSizedArrayType - setObjectLinkingLayerCreator - llvm/llvm-project@b18e5b6 - memory manager factory - llvm/llvm-project@ea709c7 - llvm/llvm-project@cd58586 - API change: getAsmStringExpr - llvm/llvm-project@911b200
- Update function signatures - getDependentSizedArrayType - TextDiagnosticPrinter - InstantiatingTemplate - ASTWriter - LANGOPT change - llvm/llvm-project@fee1689
…ssible FIXME: Copy some of the upstream functions in.
This is a rather huge change and might break things. There might be some things that might be missing/wrong here. Need to test/look at this patch again for things that I might've missed. Ref: llvm/llvm-project#147835
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
…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
…plateNames Fix tests: - pyunittests-bindings-pyroot-cppyy-cppyy-test-advancedcpp - root-io-newstl-run
…QualTypeNames.cpp We need to revisit this since this might not be the only place where we might need this. Maybe extract this into a separate function and use this wherever we have a prefix.
… 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.
…or Kind::Type Restrict the early return to Kind::Type prefixes only, and let other types fall through to the substitution logic so that Double32_t and the likes are properly handled. REVISIT: Do we even need this check now? Fix the following failing tests: - gtest-tree-dataframe-dataframe-snapshot-emptyoutput - roottest-root-meta-runGetMissingDictionaries-auto
Fix failing tests: - pyunittests-bindings-pyroot-cppyy-cppyy-test-lowlevel - pyunittests-bindings-pyroot-cppyy-cppyy-test-datatypes
…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
This functionality seems to be used in multiple places, wrap this in a function so that this can be reused.
We need some changes in cling to make it not assert and fail during build/test. We rely on these a lot and can't afford to assert at these places. Fixes were attempted upstream but later got fixed in a different way: - llvm/llvm-project@1f9c54a - llvm/llvm-project@720abd7 Also fix errors with UnaryTransformTypes. Reproducer: ``` cling> namespace N { struct D {}; } cling> __remove_extent(N::D)* x; x // asserts ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
TODO:
Changes or fixes:
Checklist:
This PR fixes #