[Lldb-commits] [PATCH] D81471: [lldb] Add support for using integral const static data members in the expression evaluator

[Andy Yankovsky via Phabricator via lldb-commits]

werat marked 6 inline comments as done.
werat added a comment.

In D81471#3632297 <https://reviews.llvm.org/D81471#3632297>, @labath wrote:

> I guess the condition we really want to express here is "does this expression refer to a constexpr variable (ideally one without a location)"? And the problem is that clang does not give us the means to detect that?
>
> Is that really the case? Would it maybe be possible to use some c++ magic to get clang to do that for us. Write something like `if constexpr (__builtin_constant_p(user_expression)) do_something_rvalue_like(); else assume_regular_lvalue();` ?

I think you're right here, but I don't know a better way to express this. My clangfu is not good enough for this yet :)

As I understand it, we can't express it purely in the expression (via `__builtin_constant_p` or something), because we need to know the answer before executing the expression (it changes the way we do materialization/dematerialization).

Could this be something to improve in the future?



================
Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2689
+      // TODO: Support float/double static members as well.
+      if (!attrs.const_value_form && !ct.IsIntegerOrEnumerationType(unused))
+        return;
----------------
Michael137 wrote:
> Should this be:
> 
> ```
> if (!attrs.const_value_form || !ct.IsIntegerOrEnumerationType(unused))
> ```
> ?
Whoops, yes, thanks!


================
Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2696
+                       "Failed to add const value to variable {1}: {0}",
+                       v->getQualifiedNameAsString());
+        return;
----------------
Michael137 wrote:
> Can `v` be `nullptr` here?
Honestly, not sure. Theoretically `AddVariableToRecordType` can return `nullptr`, but I've never seen such case. Maybe it only happens when the debug info is malformed? Would that be caught earlier at some stage?
I can add a safe guard here with a log message.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81471/new/

https://reviews.llvm.org/D81471