[PATCH] D127082: [clangd] Add Macro Expansion to Hover
Qingyuan Zheng via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jul 19 22:18:16 PDT 2022
daiyousei-qz marked 5 inline comments as done.
daiyousei-qz added a comment.
I have also moved the expansion out of the location checking branch. I think it's to find out if a macro actually has a definition which isn't always the case especially for special macros like `__FILE__`.
Here's the current presentation.
F23848502: image.png <https://reviews.llvm.org/F23848502>
F23848497: image.png <https://reviews.llvm.org/F23848497>
F23848508: image.png <https://reviews.llvm.org/F23848508>
================
Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:490
+ HI.Definition = "#define MACRO 41";
+ HI.MacroExpansion = "41";
+ }},
----------------
sammccall wrote:
> this is redundant with the definition, ideally I think we'd omit one (the output is pretty heavyweight).
>
> It's *almost* correct to omit the expansion for object-like macros, the problem with this is:
> ```
> #define INDIRECT DOUBLE(y)
> #define DOUBLE(X) X##X
> int INDIRECT; // we *should* show expansion here
> ```
>
> Still, this is probably rare enough that it's better to not show expansions for object-like macros on balance?
>
> (It would be possible to actually check for nested expansions but I doubt it's worth the complexity, certainly not in this patch)
I suppose if we don't have good way to detect nested object-like macro, just leave both definition and expansion is a better idea since people could simply ignore the redundant part. Though I don't have a strong opinion on this and could change that if you really want.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127082/new/
https://reviews.llvm.org/D127082
More information about the cfe-commits
mailing list