Type information in hover response useless in some cases about clangd HOT 10 CLOSED

Agree, returning the type as written is nice in some cases (it's usually terse!) but is catastrophically bad for auto and... mixed at best for things like value_type.

The YCM + libclang logic looks more sensible at first glance, we may also be able to enhance some cases further with access to the C++ API.

from clangd.

Ah, so I'd forgotten the tricky issue here.

As you've seen there's no "type information" request in LSP, just the "hover" request with as unstructured response.
I think the idea behind our current hover responses is that pretty-printing the decl gives a sense of:

• the kind of thing that's being hovered (a variable?)
• a sense of where it came from (namespace?)
• its type (int?)
• its definition (= 42)
• its documentation, maybe

But it's not doing a great job of any of these, and then we've bound the response to :YcmCompleter GetType where users rightly expect a detailed type and nothing else.

I think we need to internally build a structured representation of the hover information, with proper detailed type info. Then we can render a nicer hover response, and probably also provide something more suitable for GetType as an extension.

Assigning to @kadircet as he's starting to look at improving hover.

from clangd.

Yes, textDocument/Hover is one of my least favourite parts of the protocol in general.

Here's a proposal how structuring Hover could work:

• Return an array of MarkedStrings
• First MarkedString can be a dictionary { "language": "cpp", "value": type_information }
• Every other MarkedString should be used for documentation (YCM's GetDoc)
  • Alternatively, instead of sending an array of strings, send one large string with embedded new lines.

That is what jdt.ls returns when both type and documentation information is available. When one of those isn't available, it might return just the dictionary or just the list of strings.

from clangd.

We'll need to make sure that as well as having accessible structure, they look good when rendered by clients naive to that structure.

There's also the issue that the MarkedString[] response is deprecated, so a MarkupContent might be preferable.

So another option would be to add extensions to MarkupContent like:

{
  "kind": "markdown",
  "value": "function ns::**foo**(v)\n\nsome doc\n\n```cpp\nvoid foo(int v);\n```",
   "name": "foo",
   "scope": "ns::",
   "type": "void(int)",
   "category": "function",
   "definition": "void foo(int v);",
   "documentation": "some doc",
}

That way we can still provide a nicely-formatted string and tweak the layout over time, but YCM can properly support GetType without any brittle parsing.

Alternatively, we could hide all this extra structure in clangd and just define new methods to get at the type.

from clangd.

I don't see MarkedString declared deprecated anywhere in the protocol specifications, even though it is older than MarkupContent.

I'm personally not a fan of markup hover response, because the editor I care about (vim) doesn't have a markup parser (at least by default).

from clangd.

I see this on the definition of MarkedString: @deprecated use MarkupContent instead.

MarkupContent can be plain text (and will be if the client doesn't advertise markdown support via capabilities)

from clangd.

This is partially addressed in llvm/llvm-project@287a874.

I say partially because we still miss pretty printing for auto types and handling of long initializer lists.
but at least, we know print the underlying type when hovering over auto typed variables.

Note that this also changes the hover output, so with next clangd release :YcmCompleter GetType functionality might need to be adjusted, happy to chat about it more.

from clangd.

Is there any chance to resolve the type of a lambda auto parameter?

foo([](auto p){});

Btw is this a duplicate of #58?

from clangd.

Is there any chance to resolve the type of a lambda auto parameter?

foo([](auto p){});

I believe that depends on the signature of foo. If the parameter type is a concrete function pointer type (e.g. void(*)(int)) and the lambda has no captures (so that it can be converted to a function pointer), then yes, we should be able to determine what the type of the instantiated parameter p for the call will be.

It's probably worth having this case on file as a separate issue, as it's kind of a special case / not the typical case of deducing auto from an initializer.

from clangd.

As Kadir mentioned, type information is now split out from the declaration (for quite a while now!). I think that's the core issue here, so we should close this bug.

I've opened separate bugs for the other issues raised here:

• huge initializers #710
• sugar on auto variables #709

from clangd.