aganea wrote: > Yes, feel free to take over that part, thanks!
@amykhuang : I took a look at https://reviews.llvm.org/D89286. It works but doesn't fix the most problematic case where the `constexpr` member needs an evaluation that relies on dependent values: ``` template <int VAL> struct C { static constexpr int constexprVal_C = VAL; }; C<200> globalC; ``` I've tried your suggestion, that is forcing evaluation of `constexpr` members upon instantiation: > Actually, can we just instantiate the initializer for static constexpr data > members? > > currently [it delays creating the initializer for inline static data > members](https://github.com/llvm/llvm-project/blob/683b308c07bf827255fe1403056413f790e03729/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp#L5062); > can we not do that if it's a constexpr? While this works for the above example, it fails a few tests in Clang, like [this one](https://github.com/llvm/llvm-project/blob/main/clang/test/CXX/expr/expr.const/p6.cpp). It might be because the constexpr expressions are only supposed to be evaluated when used. I'm not sure what a good way forward would be if we wanted to fix this. @zygoloid (note: this is only to generate constants in the debug info). Overall this is a minor issue and I've fixed it by switching to a plain `const`. The root issue is that we have .NATVIS files that are referencing these otherwise unused members. If we wanted to do things the right way, perhaps NATVIS merged into the PDB would need to be evaluated at compile time, but that sounds like a lot of work. Also, NATVIS come too late in the process, at link time. Hopefully, Visual Studio has a debug mode where failed NATVIS evaluations are shown in the debug output, so they are easy to spot. https://github.com/llvm/llvm-project/pull/95259 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
