clayborg wrote: > > > Few minor issues, but looks good to me. (you metnioned somewhere an lldb > > > issue I think with this patch when the value is removed from the static > > > member declaration inside the class? If that's a problem - probably hold > > > off on committing this until lldb's been fixed so this doesn't regress > > > things? And document the dependence clearly in the commit message) > > > > > > I saw the patch to lldb to test that we can find global variables that are > > `constexpr`. In upstream, we can't use find global variables, but the > > expression parser does work for these. We should make sure that both > > `FindGlobalVariables(...)` and expression parsing work for all `constexpr` > > globals. > > Yup, the expression evaluator finds them by looking at the > `DW_AT_const_value` on the declaration. But since we're moving that constant > onto the definition with this patch, that will break that codepath. > > Looking into how best to address that now
The DWARFASTParserClang.cpp will try to create the class from the DWARF for the class definition. You will need to find the `DW_TAG_variable` when we are creating the static field if there is no `DW_AT_const_value` in the `DW_TAG_member`. But we also need to support the `DW_AT_const_value` being in the `DW_TAG_member` since older DWARF will be emitted like this. Are we going to emit a `DW_AT_const_expr` now in the `DW_TAG_member`? If so, then we will know that we need to look for the DW_TAG_variable. I don't think clang emitted the `DW_AT_const_expr` attribute before. The other option it to just see if the expression parser works since global variables are found correctly. Maybe the same will happen in this case? https://github.com/llvm/llvm-project/pull/70639 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
