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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
