This currently populates only the Name with the expression's type and
Value if expression is evaluatable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Basing this on the hover for the type doesn't seem right. e.g. int should be the Type rather than the Name.
Rather than printing the value if evaluable, I think we should only show the hover if evaluable. There's a cost to showing it and the value of just the type doesn't seem clearly high enough.
I think we should avoid triggering for literals. Maybe some exceptions, but a hover saying that 0 is an int with value 0 seems silly.
Hovering over IntegerLiteral/FloatingLiteral may be useless, but I think it's useful when hovering over StringLiteral/UserDefinedLiteral/CXXNullPtrLiteralExpr ....
- "hello" -> char [6].
- nullptr -> std::nullptr_t.
- 1i -> std::complex<double>.
agreed.
I believe all but the first case seems redundant. So I am only keeping the StringLiterals and dropping the rest.
clang-tools-extra/clangd/Hover.cpp | ||
---|---|---|
431 | I'd really like to avoid *any literals here in the initial patch. While there may be value in hover to see string length, I'm not sure the generic expr display code (which happens to show a type, which happens to include length) is the best way to get at this - seems pretty clunky. (Similarly I think there's a case for UDLs, maybe showing numbers in different bases etc - but that's not the central point of this patch, so let's not try to work out exactly where the line is) | |
438 | you could extract a isLiteral(StmtClass) function here and dispense with the second half of this comment, if you like. | |
528 | I don't think it's a good idea to try to infer here what's being hovered on from which fields happen to be set, or to bail out assuming there's no documentation etc. (e.g it would be pretty reasonable for a UDL to return the doc of the operator as doc). I'm also not sure abandoning the standard layout of properties is such a good idea, vs e.g. Binary expressionType: int which would be consistent with the others (and simpler here). Expression: intValue = 4 Which still requires some special-casing, but less. |
Unit tests: pass. 61794 tests passed, 0 failed and 781 were skipped.
clang-tidy: unknown.
clang-format: pass.
Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
I'd really like to avoid *any literals here in the initial patch.
While there may be value in hover to see string length, I'm not sure the generic expr display code (which happens to show a type, which happens to include length) is the best way to get at this - seems pretty clunky.
(Similarly I think there's a case for UDLs, maybe showing numbers in different bases etc - but that's not the central point of this patch, so let's not try to work out exactly where the line is)