[PATCH] D148457: [clangd] Support macro evaluation on hover

[Younan Zhang via Phabricator via cfe-commits]

zyounan added a comment.

Haha. My bad for misunderstanding.

> I think rather if the common ancestor isn't completely selected, evaluation shouldn't happen.

I don't think it is a feasible approach to simply opt out of partial selection. Please consider this snippet:

  #define SizeOf sizeof
  void check() {
    Siz^eOf(int);
  }

And associative selection tree:

  Built selection tree
   TranslationUnitDecl 
     FunctionDecl void check()
       CompoundStmt { …
        .UnaryExprOrTypeTraitExpr sizeof(int)  # Partial selected. Exclude it?

Obviously we're expecting evaluation on such macro (which is just what the original issue addresses). And it's worth noting that if we define the macro a whole expression e.g., `sizeof(int)`, rather than a token `sizeof`, the common ancestor will be seen as completely selected.

OTOH, it doesn't seem so trivial to me to tell if an expression or token is appropriate (or to say, full enough?) to evaluate. Take Nathan's case for example. The macros `#define PLUS_TWO +2` and the `#define PLUS_TWO 2` are both transformed into the same AST. The mapped selection tree is,

  .BinaryOperator 40 + 2
     *IntegerLiteral 2  # For either '40 PLU^S_TWO' or '40 + PLU^S_TWO'

...or even more extreme,

  #define PLUS_TWO +2
  40 + PL^US_TWO;  // it should be seen as '+2', right?

As of now I didn't come up with a better idea to split the cases. Any suggestion? :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148457/new/

https://reviews.llvm.org/D148457