[PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D112374#3657640 <https://reviews.llvm.org/D112374#3657640>, @mizvekov wrote:

> In general, I would not expect external tools to care about the shape of the AST. I would expect the type API would be used in a way where we ignore a type sugar node we have no reason to acknowledge.
> Ie you query if some type is a (possible sugar to) X, and you would either get X or nothing. The type sugar over it would just be skipped over and you would have no reason to know what was in there or what shape it had.

I'm afraid your expectations are wrong, and not by a little bit :-)

I totally agree this is the best way to the use the AST: understanding what you want to depend on and what groups of differences (e.g. sugar) to ignore, and writing code that expresses that intent.

However this is empirically not how lots of downstream (and plenty of in-tree) code is written, because:

- it requires a deep understanding of the "philosophy" of the AST to understand where extensions are possible in future
- many people write AST traversals using matchers, which constrains and obscures exactly what's being matched
- many people write AST trawling code based on AST dumps of examples, rather than a first-principles approach
- it is difficult and tedious to test
- people are often only as careful as they're incentivized to be

I've seen plenty of (useful) out-of-tree tidy checks written by people fuzzy on the difference between a Type and a TypeLoc, or what sugar is. Clang makes it (almost) easy to write tools but hard to write robust tools.

All of this is to say I like this change & appreciate how willing you are to help out-of-tree tools (which is best-effort), but I expect a lot of churn downstream. (And LLVM has a clear policy that that's OK).

(BTW, last time I landed such a change, investigating the LLDB tests was indeed the most difficult part, and I'm not even on windows. Running a linux VM of some sort might be your best bet, unfortunately)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374