Root llvm22#233
Open
smuzaffar wants to merge 30 commits into
Open
Conversation
- 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 - API changes related to SFINAE - llvm/llvm-project@d2f75f2 - Replace getContext with WithContextDo - llvm/llvm-project@0bfa0bc
Unloading an invalid TopLevelStmtDecl can trigger assertions. This is caused by the upstream change llvm/llvm-project@4b70d17bcf causing an invalid TopLevelStatement to be added to the AST, this can trigger assertions when we try to dump/print AST.
- Update function signatures - getDependentSizedArrayType - TextDiagnosticPrinter - InstantiatingTemplate - ASTWriter - LANGOPT change - llvm/llvm-project@fee1689
This functionality seems to be used in multiple places, wrap this in a function so that this can be reused.
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
This is a rather huge change and might break things. Ref: llvm/llvm-project#147835
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 ```
…andling Fix failing tests: - pyunittests-bindings-pyroot-cppyy-cppyy-test-lowlevel - pyunittests-bindings-pyroot-cppyy-cppyy-test-datatypes
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 `CLANG_CMAKE_DIR` after the changes in: llvm/llvm-project@88b77073 We also need to add a patch to clad to get this building.
Author
|
test parameters:
|
|
A new Pull Request was created by @smuzaffar for branch cms/master/6bf5355cc45. @akritkbehera, @cmsbuild, @iarspider, @raoatifshad, @smuzaffar can you please review it and eventually sign? Thanks. |
|
cms-bot internal usage |
Author
|
please test |
|
-1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-373920/54303/summary.html Failed External BuildI found compilation error when building: + echo 'test $?PY3_NUMPY_ROOT != 0 || source /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/el9_amd64_gcc13/external/py3-numpy/1.26.4-6c7401133d71aa0fdd19f4799dadfbdf/etc/profile.d/init.csh'
+ echo fi
+ touch /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/etc/profile.d/.autodependencies
Processing files: lcg+root+6.41.1-25f2180ee204e9858052369b955f3f20-1-1.x86_64
warning: absolute symlink: /opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock -> /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock-71c15b9d
error: Symlink points to BuildRoot: /opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock -> /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock-71c15b9d
RPM build warnings:
Macro expanded in comment on line 497: %{pkginstroot}/lib
Macro expanded in comment on line 498: %{pkginstroot}
|
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.
CMSSW tests for root-project#21658