sammccall added a comment.
In D149677#4356863 <https://reviews.llvm.org/D149677#4356863>, @aaron.ballman
wrote:
> I'm not seeing how the changes you've got here interact with
> `isScopeVisible()`; However, I also note that the only use of
> `isScopeVisible()` in tree is in clangd, so also adding @sammccall to see if
> they're hitting issues there or not.
I don't think I can offer much experience one way or the other.
clangd's original use of this extension point was in printing deduced types
(replace `auto` with a concrete type) so usually there was no sugar on the
types.
In other cases we're e.g. generating function signatures, and happy with
*either* type-as-written-somewhere-in-the-code *or*
type-relative-to-enclosing-namespace, as long as we're not producing some long
qualified form that nobody would ever write.
> We typically don't add new printing policies in tree without some need for
> them in the project itself (otherwise this becomes a maintenance problem),
> and I'm not certain I see a strong need for this to live in Clang
The maintenance concern makes sense ("why do we have this, and can do we still
need it" needs to be an answerable question).
But this paints out-of-tree users into a corner: the designs clang has chosen
here only really allow extension in two places:
- customize the printing, but this can *only* be done in TypePrinter (or
reimplement the whole thing)
- replace the sugar on the types before printing, but TreeTransform is private,
and any other solution requires tightly coupling with the full set of types
Clang supports
I think if we want clang to be a generally-useful representation of the source
code then we need to make concessions to out-of-tree use-cases either directly
or via extensibility.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D149677/new/
https://reviews.llvm.org/D149677
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
