[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction
Matheus Izvekov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 23 15:57:38 PDT 2021
mizvekov added inline comments.
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:495
+ const QualType &Type,
+ bool Underlying = false) {
const auto &SM = AST.getSourceManager();
----------------
sammccall wrote:
> (i'm confused by the optional parameter - there's only one caller)
Oh I must have just assumed there were other callers, will fix.
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:506
+ targetDecl(DynTypedNode::create(Type.getNonReferenceType()),
+ DeclRelation::TemplatePattern | DeclRelation::Alias |
+ (Underlying ? DeclRelation::Underlying : DeclRelation()),
----------------
sammccall wrote:
> `Alias | Underlying` means that go-to-definition will return both A and B in this case:
>
> ```
> using A = int;
> using B = A;
> au^to x = B();
> ```
>
> I don't think we particularly want that.
>
> Really this change is just trying to make sure we can resolve `decltype(auto) -> decltype(foo) -> Foo` right? I think we should rather make clangd::getDeducedType(...) unwrap the decltype(foo) in the first place.
I think that one is to make sure we can look through extra DeducedType sugar when finding some definition.
Specifically a case like the 'auto on lamda' from XRefsTests:
```
auto x = [[[]]]{};
^auto y = x;
```
`y` will have an extra layer of AutoType sugar there, since it deduced from something which already had AutoType sugar.
But maybe the way I implemented that in clangd is not good. I will take a look again, thanks for the explanation.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110216/new/
https://reviews.llvm.org/D110216
More information about the cfe-commits
mailing list