[lldb-dap] Hover on objc declarations vs expressions is different

[ashgti]

I'm looking into updating lldb-dap's expression request and digging into this I found some inconsistencies with how we're evaluating terms in the hover request.

Specifically, if you have some obj-c code like:

  MyType *foo = [[MyType alloc] init];
  [foo doWork];

If you hover over the declaration of foo VSCode is actually sending a hover request for *foo. If you hover over foo when its about to invoke a method, it will send a request for foo.

When we call frame.GetValueForVariablePath with the first form, its dereferencing the variable. Which is a totally valid expression, but not what I think the user meant when they hover over the variable.

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: John Harrison (ashgti)

I'm looking into updating lldb-dap's expression request and digging into this I found some inconsistencies with how we're evaluating terms in the hover request.

Specifically, if you have some obj-c code like:

  MyType *foo = [[MyType alloc] init];
  [foo doWork];

If you hover over the declaration of foo VSCode is actually sending a hover request for *foo. If you hover over foo when its about to invoke a method, it will send a request for foo.

When we call frame.GetValueForVariablePath with the first form, its dereferencing the variable. Which is a totally valid expression, but not what I think the user meant when they hover over the variable.

[ashgti]

This actually also affects & c++ parameters as well, I think its taking the address of the variable, not considering the declaration.

[ashgti]

In VSCode, the way the terms are broken up is to use a EvaluatableExpressionProvider (https://code.visualstudio.com/api/references/vscode-api#EvaluatableExpressionProvider) if one is provided for the language, or to use a regex to break up the line into terms (https://github.com/microsoft/vscode/blob/03394e2fa7ef7f60c055771802c74fc7b93ed0fb/src/vs/workbench/contrib/debug/common/debugUtils.ts#L84).

We could look into handling this from the clangd side of things, or we could try to mitigate this in lldb-dap.