2026 Project Roadmap #782
Description
Description of new feature
This is a meta issue to track and prioritize work items that feed back into stability, reliability and integration in projects such as cppyy and ROOT.
NOTE: The jank-lang fork of CppInterOp has a lot of improvements already and the author has mentioned he wants to contribute them back to mainstream but has no time. Before solving an issue, we should check if it is not already solved and just bring back the patch.
Items required to be completed before the next release:
- Complete the support of
dlopen(CppInterOp.so, RTLD_LOCAL). Depends on Add CppInterOp API Dispatch mechanism #780
Good issues to start with which have relatively high priority.
- Create consistent
PrintingPolicyduring theCreateInterpreterphase #662 - [Feature Request]: Full member function support in
BestOverloadFunctionMatch#590
Improvements in CppInterOp:
- Allow users to subscribe for produced diagnostics. We can implement a custom diagnostics consumer such as done in llvm-project/clang/unittests/ (git grep DiagnosticConsumer in that folder). The user should provide a callback that fires when we encounter a diagnostic passing back the diagnostic kind and message.
- Implement a generic diagnostic system in CppInterOp. We can take inspiration from the state-based diagnostic systems of opengl or python where the operations possibly push diagnostics on a diagnostic stack and then they need to be checked explicitly on the client side. That keep the interfaces relatively simple and compatible with C. Possibly related to the previous item.
- Implement a facility that captures the output when running. If we run the CppInterOp tests (make check-cppinterop) we can see that the google tests are producing a lot of output on the terminal. This should be handled by the system or the testsuite itself.
- Improve type safety of the public interfaces. Right now each interface is a typedef over a
void*and it accepts virtually anything. Even expert users fall into traps when passing arguments. We should take inspiration from libClang (and our C interface) where the interfaces are cursor-based. This is, we can make sure that an interface takes a specific declaration kind (checks enforced by the compiler). Similar issue Improve type safety CPyCppyy#8
Improvements regarding cppyy:
- Remove the need of
AppendTypesSlowinterfaces. They were implemented in the beginning of the migration so that we can postpone dealing with issues at that time. In essence we re-introduce string parsing which can be avoided. - Minimize the occurrences of
Cpp::Declare-- they generally use string parsing. - Rework the way templates are modeled in CpyCppyy. The previous approach could not make use of the direct type pointers and recalculated strings. We do not need to do this anymore as we have more robust api and access to the compiler internals.