[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)

[Pavel Labath via lldb-commits]

================
@@ -511,22 +513,58 @@ ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
     VariableSP &var_sp, Status &error) {
   ExecutionContext exe_ctx;
   CalculateExecutionContext(exe_ctx);
+
   bool use_DIL = exe_ctx.GetTargetRef().GetUseDIL(&exe_ctx);
+
   if (use_DIL)
     return DILGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
                                                 var_sp, error);
-
-  return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
-                                                 var_sp, error);
+  else
+    return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
+                                                   options, var_sp, error);
 }
 
 ValueObjectSP StackFrame::DILGetValueForVariableExpressionPath(
     llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
     uint32_t options, lldb::VariableSP &var_sp, Status &error) {
-  // This is a place-holder for the calls into the DIL parser and
-  // evaluator.  For now, just call the "real" frame variable implementation.
-  return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
-                                                 var_sp, error);
+  ValueObjectSP ret_val;
+  std::shared_ptr<std::string> source =
+      std::make_shared<std::string>(var_expr.data());
+
+  const bool check_ptr_vs_member =
+      (options & eExpressionPathOptionCheckPtrVsMember) != 0;
+  const bool no_fragile_ivar =
+      (options & eExpressionPathOptionsNoFragileObjcIvar) != 0;
+  const bool no_synth_child =
+      (options & eExpressionPathOptionsNoSyntheticChildren) != 0;
+
+  // Parse the expression.
+  Status parse_error, eval_error;
+  dil::DILParser parser(source, shared_from_this(), use_dynamic,
+                        !no_synth_child, !no_fragile_ivar, check_ptr_vs_member);
+  dil::DILASTNodeUP tree = parser.Run(parse_error);
+  if (parse_error.Fail()) {
+    error = std::move(parse_error);
+    return ValueObjectSP();
+  }
----------------
labath wrote:

The benefits are definitely open to interpretation and we can skip this if you feel strongly about it, but my reasoning is: the functionality which the DILParser class implements is.. well.. a function -- you put the expression string (plus some other data) in, and you get a parsed tree out. After the caller doesn't, the caller doesn't need/want to refer back to the parser object. Putting it into the function makes the whole parser object an implementation detail, which is what I think it is in this case. The situation would be different if we wanted to use the same parser object for parsing multiple expressions. In that case, the two step process would be justified and necessary. 

https://github.com/llvm/llvm-project/pull/120971