[clangd] Hide inlay hints when using a macro as a calling argument that with a param comment

[zyounan]

Summary

We don't want to produce inlay hints for arguments for which
user has left param name comments. But we're not decomposing
location of the parameter correctly at the moment because the
location we've passed into SM.getDecomposedLoc is not always
FileID.

Fixes clangd/clangd#1495

[zyounan]

Note that we still have some issues on inlay hints with macro expansion even after D133982.

void func(int a, int b);
#define CALL(a, b) func(int(a), b)

CALL(3, 4);  // CALL(3, b: 4)

This is because spelledForExpanded doesn't return counterpart spelling ( int(3) -> 3 ). (I guess it is due to patch D134618.)

void func(int a, int b);
void work(int a, int &b);
#define CALL(a, b) { func(int(a), b); work(a, b); }

int z = 42;
CALL(3, z);  // CALL(a: 3, &b:b: 4)

This is because call expression handling logic (i.e. InlayHintVisitor::processCall) doesn't know the macro expansion context of expression, resulting producing two inlay hints at the same spelled position.

[zyounan]

clang-tools-extra/clangd/InlayHints.cpp

521

stupid question: I was suspicious with this check that when would Decomposed.first not being the same as MainFileID? Should the "top-caller" of the macro always be in main file? I didn't find a case that differs, except when getDecomposedLoc provides wrong FileID.

[zyounan]

Ping

[nridge]

clang-tools-extra/clangd/InlayHints.cpp

519–520

I admit I struggle with this spelling/expansion loc stuff. But having spent a bit of time reading the implementations of these functions, would I be correct to say that another, perhaps easier to follow, way to express the same thing would be:

auto Decomposed = SM.getDecomposedLoc(SM.getFileLoc(E->getBeginLoc()));

?

521

I tried adding an assertion in this early-return branch, and it tripped in ParameterHints.IncludeAtNonGlobalScope.

The code there is:

Annotations FooInc(R"cpp(
  void bar() { foo(42); }
)cpp");
Annotations FooCC(R"cpp(
  struct S {
    void foo(int param);
    #include "foo.inc"
  };
)cpp");

so I guess the decomposed loc there is a file loc, but not in the main file (but rather in foo.inc).

[zyounan]

Address the comments

clang-tools-extra/clangd/InlayHints.cpp

519–520

Yes, indeed. SM.getFileLoc performs exactly the same function as getTopMacroCallerLoc and getDecomposedExpansionLoc:
If Loc is a FileID, just return Loc.
In another case it falls into a loop until the result is a FileID: First obtain the "top macro caller" location, then the beginning expansion location.

521

Ah, I see. Thanks!

[zyounan]

Update

[nridge]

Thanks!