[lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath

[kastiglione]

Summary

The frame variable command supports an implicit this/self, allowing a
user to run v some_field instead of v this->some_field. However, some
languages have non-pointer this/self types (for example, Swift).

This change adds support for non-pointer implicit this/self. This is done
by consulting the type of the instance variable. If the type is known to be
non-pointer, the dot operator is used instead of the arrow operator.

The C language of families each have a pointer instance type, which makes
testing of this difficult. Tests for this feature will be done in the Swift
downstream fork, as Swift's self is a non-pointer (reference) type.

rdar://82095148

[kastiglione]

use explicit type instead of auto

[kastiglione]

check valid compiler type

[aprantl]

This is good, but it also illustrates how the strings "->" and ".'" should actually come from the typesystem and not be hardcoded. We're just lucky that all languages have a "." operator.

[aprantl]

More elegant would be to just add an API to TypeSystem to get the operator to access ivars.

[kastiglione]

This is good, but it also illustrates how the strings "->" and ".'" should actually come from the typesystem and not be hardcoded. We're just lucky that all languages have a "." operator.

More elegant would be to just add an API to TypeSystem to get the operator to access ivars.

Initially I was thinking along these lines. But I became less sure. The "variable expression path" syntax is C-like but independent of the source language. For example, in Swift, there is no ->. So my rhetorical question is, should the Language or TypeSystem, etc, know about "variable expression path" syntax, as you suggest? Or should we rely on there being a shared subset between source language and variable expression path syntax, and allow the two subsystems to think they're speaking the same language even though we know they're each actually speaking a different but partially compatible language (source vs variable expression path).

I decided to keep the ->/. choice inside GetValueForVariableExpressionPath because I feel that kind of logic belongs closer to other variable expression path code.

[jingham]

In D127605#3580123, @kastiglione wrote:

This is good, but it also illustrates how the strings "->" and ".'" should actually come from the typesystem and not be hardcoded. We're just lucky that all languages have a "." operator.

More elegant would be to just add an API to TypeSystem to get the operator to access ivars.

Initially I was thinking along these lines. But I became less sure. The "variable expression path" syntax is C-like but independent of the source language. For example, in Swift, there is no ->. So my rhetorical question is, should the Language or TypeSystem, etc, know about "variable expression path" syntax, as you suggest? Or should we rely on there being a shared subset between source language and variable expression path syntax, and allow the two subsystems to think they're speaking the same language even though we know they're each actually speaking a different but partially compatible language (source vs variable expression path).

I decided to keep the ->/. choice inside GetValueForVariableExpressionPath because I feel that kind of logic belongs closer to other variable expression path code.

The original intention of the variable expression paths was that they were really about navigating the ValueObject hierarchy, and the syntax we use should be governed by how to do that most conveniently, without being bound by the variety of languages that might underly that ValueObject hierarchy. That's particularly convenient when you get to synthetic children, which aren't necessarily bound to the language in which the types are expressed.

lldb/source/Target/StackFrame.cpp

ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
   bool synthetically_added_instance_object = false;
 
   if (var_sp) {
     var_expr = var_expr.drop_front(name_const_string.GetLength());
   }
 
   if (!var_sp && (options & eExpressionPathOptionsAllowDirectIVarAccess)) {
     // Check for direct ivars access which helps us with implicit access to
-    // ivars with the "this->" or "self->"
+    // ivars using "this" or "self".
     GetSymbolContext(eSymbolContextFunction | eSymbolContextBlock);
     lldb::LanguageType method_language = eLanguageTypeUnknown;
     bool is_instance_method = false;
     ConstString method_object_name;
     if (m_sc.GetFunctionMethodInfo(method_language, is_instance_method,
                                    method_object_name)) {
       if (is_instance_method && method_object_name) {
         var_sp = variable_list->FindVariable(method_object_name);
         if (var_sp) {
           separator_idx = 0;
+          if (Type *var_type = var_sp->GetType())
+            if (auto compiler_type = var_type->GetForwardCompilerType())
+              if (!compiler_type.IsPointerType())
+                var_expr_storage = ".";
+
+          if (var_expr_storage.empty())
             var_expr_storage = "->";
           var_expr_storage += var_expr;
           var_expr = var_expr_storage;
           synthetically_added_instance_object = true;
         }
       }
     }
   }