[clangd] Show Value on hover for objects representable at constexpr

[torshepherd]

Currently, hovers on basic values like const char* display their constexpr value:

However, hovers on structs and other objects don't show a value:

They could feasibly use one of three strategies for displaying a value:

1. Do the same thing that P2741R3 does; if the type has .data() and .size() methods, treat it as a way to display the values and use them to render characters in the hover.
2. if the type has a constexpr ostream operator, constexpr formatter specialization, etc. use that.
3. __builtin_dump_struct or similar method of displaying the fields

I think #1 is the cleanest, and as more things become possible at constexpr this could be useful for debugging constexpr code more easily.

[torshepherd]

I see actually that we could simply not exit early on structs/unions:

  // Attempt to evaluate. If expr is dependent, evaluation crashes!
  if (E->isValueDependent() || !E->EvaluateAsRValue(Constant, Ctx) ||
      // Disable printing for record-types, as they are usually confusing and
      // might make clang crash while printing the expressions.
      Constant.Val.isStruct() || Constant.Val.isUnion()) {

We definitely don't want to add clang crashes with this 😅, but I think an additional check here for "could this be a user-generated static_assert message" would be simple enough and safe

[torshepherd]

Ah, this is actually nontrivial because all of that logic lives in Sema::EvaluateStaticAssertMessageAsString, not Expr::EvaluateCharRangeAsString... so we either have to replicate the logic for looking up and evaluating data() and size(), or tie Hover to Sema (probably not right), or pull EvaluateStaticAssertMessageAsString out from Sema?

[llvmbot]

@llvm/issue-subscribers-clangd

Author: Tor Shepherd (torshepherd)

Currently, hovers on basic values like `const char*` display their constexpr value:

However, hovers on structs and other objects don't show a value:

They could feasibly use one of three strategies for displaying a value:

1. Do the same thing that P2741R3 does; if the type has .data() and .size() methods, treat it as a way to display the values and use them to render characters in the hover.
2. if the type has a constexpr ostream operator, constexpr formatter specialization, etc. use that.
3. __builtin_dump_struct or similar method of displaying the fields

I think #1 is the cleanest, and as more things become possible at constexpr this could be useful for debugging constexpr code more easily.

[HighCommander4]

we either have to replicate the logic for looking up and evaluating data() and size(), or tie Hover to Sema (probably not right), or pull EvaluateStaticAssertMessageAsString out from Sema

We do have access to Sema if we need it (ParsedAST::getSema()), though whether a particular function is suitable for calling from clangd probably varies from one function to another. I think the main thing to watch out for is side effects like producing diagnostics; if the function has such side effects, the code may need some light refactoring to make those side effects optional for clangd's call site.